Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitFlow considered harmful

endoflineblog.com

Post reply on HN
Print view View original

331–340 of 342 posts

Re: GitFlow considered harmful

#331

Post by qu4z-2 »

pyre wrote: post #301
wylee wrote: post #134

Earlier quoted context omitted.

I agree with you, but only for local commits that haven't been pushed to a shared repo. Rewriting local history seems no different than rewriting code in your editor. Rewriting shared history is (almost) always bad.

Making 'temporary' commits and rewriting local history before pushing to a shared repo has analogs in other revision control systems: * In Subversion, people track patches using tools like quilt to manage them before actually putting them together into a commit. * In Mercurial, people use `hg mq` which is like a more featureful version `git-stash`. These are basically all ways to track a series of patches prior to 'c…

Speaking of `git-stash` I've always thought of `git-stash` as a less featureful version of `git-branch stash`

Re: GitFlow considered harmful

#332

Post by qu4z-2 »

damm wrote: post #298
hayd wrote: post #280

Earlier quoted context omitted.

Then someone else rebases over that commit, there's a conflict and lo! the tests fail. Why? typo. It's fixed in the subsequent commit (which you can't see). Lovely. There's something to be said for having every commit pass tests/work (or if it doesn't saying explicitly in the commit message), if anyone is ever going to step over this commit.

That's a hard one; trying to make a single commit in a pull request helps me but sometimes even then a pull request gets ignored and they want me to rebase it. The problem is they ask /me/ to rebase it; I think they should take a little ownership in the potential rewriting of history.

There's no potential rewriting of history before they merge your pull request, only a series of unaccepted draft commits. :)

Re: GitFlow considered harmful

#333

Post by sytse »

lgp171188 wrote: post #197
sytse wrote: post #177

Earlier quoted context omitted.

Please let me know what you think we should improve to support that workflow better. Anyway, I think my examples are still valid, it is harder to mention issues and you can't push (write) commits on forks since your have read permissions.

I have already created a feature request here - http://feedback.gitlab.com/forums/176466-general/suggestions... The main assumption in the Integration-Manager workflow is that code from repositories of other users is always pulled by the owner of the current repository as and when appropriate. So if dev1 and dev2 are working on the same feature in 2 different forks of the main repository, dev1 has to pull commits fro…

Thanks for leaving a feature request, I commented there.

Re: GitFlow considered harmful

#334

Post by sytse »

Mithaldu wrote: post #194
sytse wrote: post #174

Earlier quoted context omitted.

Parent was deleted.

Ugh dammit. Short version: Instead of taking the branch and rebasing it, make a branch called .1 on top of , then rebase that, leaving in place. That way all your references remain intact and you can compare CI results. Increment the number as needed.

It solves the issue of the CI references. But it also seems a bit clumsy to me.

Re: GitFlow considered harmful

#335

Post by talideon »

sbov wrote: post #163
wylee wrote: post #134

Earlier quoted context omitted.

I agree with you, but only for local commits that haven't been pushed to a shared repo. Rewriting local history seems no different than rewriting code in your editor. Rewriting shared history is (almost) always bad.

Does anyone advocate rewriting shared history? Oddly I see this "exception" a lot in reply to this person but I'm not sure I ever read anywhere anyone saying rewriting shared history is a good idea.

Only in extreme circumstances where something sensitive (such as credentials) or otherwise (such as other people's copyrighted assets, or .svn directories in the case of some repos that were moved from SVN to get in a hamfisted manner) was checked into the repository and needs to be removed. Those are the only reasons for rewriting shared history.

Re: GitFlow considered harmful

#336

Post by talideon »

moron4hire wrote: post #183
wylee wrote: post #134

Earlier quoted context omitted.

I agree with you, but only for local commits that haven't been pushed to a shared repo. Rewriting local history seems no different than rewriting code in your editor. Rewriting shared history is (almost) always bad.

I don't think I've ever seen anyone advocate rewriting shared history.

I've came across reasons, but they've always been pretty marginal, such as somebody checking in sensitive credentials without realising what they were doing.

Re: GitFlow considered harmful

#337

Post by moron4hire »

talideon wrote: post #336
moron4hire wrote: post #183

Earlier quoted context omitted.

I don't think I've ever seen anyone advocate rewriting shared history.

I've came across reasons, but they've always been pretty marginal, such as somebody checking in sensitive credentials without realising what they were doing.

I think I would like the ability to edit commit messages for typos without having to force everyone to reset --hard.

Re: GitFlow considered harmful

#338

Post by Mithaldu »

sytse wrote: post #334
Mithaldu wrote: post #194

Earlier quoted context omitted.

Ugh dammit. Short version: Instead of taking the branch and rebasing it, make a branch called .1 on top of , then rebase that, leaving in place. That way all your references remain intact and you can compare CI results. Increment the number as needed.

It solves the issue of the CI references. But it also seems a bit clumsy to me.

It's all trade-offs. The trade-off being that you maintain history by having copies of a branch around, while the dude trying to fix a bug doesn't have to break out the vodka bottle upon arriving back home. :)

Re: GitFlow considered harmful

#339

Post by talideon »

moron4hire wrote: post #337
talideon wrote: post #336

Earlier quoted context omitted.

I've came across reasons, but they've always been pretty marginal, such as somebody checking in sensitive credentials without realising what they were doing.

I think I would like the ability to edit commit messages for typos without having to force everyone to reset --hard.

The thing is, the commit message is part of the commit, not something separate from it. Irritating as it might be, this is good for traceability.

What I do to avoid that is work on a separate branch, rebase against master, then review the commits on my branch after getting rid of any WIP commits and shuffling them around to make more sense. Finally, I make sure the commit messages are (a) accurate and (b) have no typos. Once I'm satisfied with that, I merge.

I treat merging as a big deal, but not committing.

Re: GitFlow considered harmful

#340

Post by sytse »

ChrisMeek wrote: post #123
sytse wrote: post #24

GitLab CEO here. I agree that GitFlow is needlessly complex and that there should be one main branch. The author advises to merge in feature branches by rebasing them on master. I think that it is harmful to rewrite history. You will lose cherry-picks, references in issues and testing results (CI) of those commits if you give them a new identifier. The power of git is the ability to work in parallel without getting i…

I'm starting to think that part of the problem we are facing at the moment is that feature branching itself can be exceptionally harmful. I see statements like "The power of git is the ability to work in parallel without getting in each-others way" and get really worried about what people are trying to achieve. I want my team's code to be continuously integrated so that problems are identified early, not at some arbi…

The idea is that you split features up in smaller parts so that you merge not more than a handful of days of work at a time.
Post reply on HN