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

Don't use Git rebase

medium.com

Post reply on HN
Print view View original

81–88 of 88 posts

Re: Don't use Git rebase

#81

Post by fredrikmorken »

andrewaylett wrote: post #24

`git rebase --exec {rebuild project}` solves the issue of invisible errors in commits. I'm a big fan of Gerrit's review workflow, which requires every commit to build in isolation. I also usually try to squash my changes into logical independent commits before review. I like rebase because it's prettier, but I also think there's an issue with the non-rebase case that the OP has missed: unless you rebase, you're setti…

Author of the article here. You bring up some interesting points, and I would not be much opposed to the workflow you describe. However, as others mention, if the problem results from a combination of changes, I would expect the merge commit to be the one that contains the error. Moving this errror to a commit that was originally part of a branch without errors is just confusing to me.

Re: Don't use Git rebase

#82

Post by fredrikmorken »

nlawalker wrote: post #61
jmull wrote: post #48

Earlier quoted context omitted.

> You should use it the other way around Yes, that's how I thought it was meant to be used. (At first I got confused reading this article because I assumed that's what they were talking about too.)

Now I'm confused... is that not what the author is doing? >> the feature branch is reset to master, after which the commits are re-applied on top of feature Is that not rebasing 'feature' on top of 'master'?

Author of the article here. Yes, this is what I am describing. Sir_Cmpwn is describing the same workflow as I am.

Re: Don't use Git rebase

#83

Post by fredrikmorken »

yyparm wrote: post #77

I tend to think the problem identified by the author is more of a fundamental problem with long-lived development branches that diverge with master - stuff will change under you and it's not always easy to notice. It's also kind of a problem if underlying parts of the system that you depend on either are churning that much without that being communicated or if they have poorly-defined interfaces and are prone to acci…

Author of the article here. You are absolutely right, and many of the other comments here suggest that people are struggling with problems that stem from the fact that their branches are long-lived.

I would encourage everyone to consider adopting trunk based development (https://trunkbaseddevelopment.com/). I expect this to solve many of the problems people have. Using short-lived feature branches that are merged every day, merges are trivial, and history easy to read. A rebase-based workflow wouldn't be that harmful if you use short-lived branches either, although the argument for preserving history still stands.

Re: Don't use Git rebase

#84

Post by andrewaylett »

fredrikmorken wrote: post #81
andrewaylett wrote: post #24

`git rebase --exec {rebuild project}` solves the issue of invisible errors in commits. I'm a big fan of Gerrit's review workflow, which requires every commit to build in isolation. I also usually try to squash my changes into logical independent commits before review. I like rebase because it's prettier, but I also think there's an issue with the non-rebase case that the OP has missed: unless you rebase, you're setti…

Author of the article here. You bring up some interesting points, and I would not be much opposed to the workflow you describe. However, as others mention, if the problem results from a combination of changes, I would expect the merge commit to be the one that contains the error. Moving this errror to a commit that was originally part of a branch without errors is just confusing to me.

A merge should be just that: merging code without adding extra changes. If you need to make changes, they should be in a separate commit.

But if you had to resolve conflicts in a merge, you might also have had to make changes, and now you've got to work out whether the breakage was because of the combination of features that hadn't been tested together before or because someone changed something while resolving conflicts. Speaking from experience, that's really difficult.

If you rebase instead, the commit that breaks the build contains the code change that breaks the build, and if it's because of a rebase error you've got the opportunity _as you're rebasing_ to detect that.

Re: Don't use Git rebase

#85

Post by andrewaylett »

golergka wrote: post #49
andrewaylett wrote: post #24

`git rebase --exec {rebuild project}` solves the issue of invisible errors in commits. I'm a big fan of Gerrit's review workflow, which requires every commit to build in isolation. I also usually try to squash my changes into logical independent commits before review. I like rebase because it's prettier, but I also think there's an issue with the non-rebase case that the OP has missed: unless you rebase, you're setti…

But that's exactly why I prefer merges - seeing that the problem wasn't in any individual branch, but resulted from the combination of changes in both is the most honest result that I would've wanted to see. Why do you label this as a 'failure'?

Because it's really difficult to disentangle changes made legitimately in supporting a merge from unintended extra changes that break things.

It also separates changes you made to implement your functionality work relative to the branch point from the extra changes you need to have your functionality work relative to the merge point. With rebase, you get the opportunity to put all the code to implement a feature in one place.

Remember that the usual caveats about writing software apply: you're doing this for the future-you and future-team-mates who come along in a few months trying to make sense of it all. Make life easy for them.

Re: Don't use Git rebase

#86

Post by hobo_mark »

joshuamorton wrote: post #79
kstenerud wrote: post #63

Earlier quoted context omitted.

This would probably be ok for smaller projects. My current codebase takes an hour and a half to build, so a rebase to master will involve anywhere from 10 to 100 rebuilds (1-10 days worth), not to mention the whole process stopping on each merge conflict, which will stretch out the rebase time even more as Murphy's Law will place every conflict outside of working hours.

What are you doing where a build takes that long (and can't be done incrementally)?

When doing anything with FPGAs for example, 90 minutes for a compilation is actually in the low side of things (and incremental builds with EDA tools have essentially never worked for me except in a tiny and unpredictable subset of cases).

Re: Don't use Git rebase

#87

Post by derimagia »

fulafel wrote: post #14
pandemi wrote: post #6

Earlier quoted context omitted.

The main use case for rebase for me is to add automatic rebases on pull to the git config. Normally if you pull from the remote and have local commits not in the remote, you'll have an "extra" merge. Automatic rebase on pull takes care of this, to avoid those useless merges.

They are not useless: they record when git used its fallible automatic merging logic to reconcile changes in two different branches. It works most of the time, but you really want to keep a record of it for later troubleshooting. Have a look at https://github.com/git/git/blob/master/Documentation/merge-s... to get some idea what is going on behind the scenes in automatic merges.

git rebase gives that just fine, even demonstrated here: https://git-scm.com/blog/2010/03/08/rerere.html.

Re: Don't use Git rebase

#88

Post by mkobit »

rout39574 wrote: post #12
thibran wrote: post #4

There is a third option nobody seems to talk about `git merge --squash` (a squashed commit bundles commits into one commit). Which produces like `rebase` a linear commit history, but preserves the single commits.

I would think squash a poor default policy; it destroys information in the granularity of commit, and in the commit messages.

I agree - you lose the build history, ability to see the incremental changes the author intended, can't go back to the code review to see what happened on that specific commit. I have a very difficult time understanding the desire to use --squash and merge --ff. The problem to me seems like a presentation issue, not a data issue.
Post reply on HN