Don't use Git rebase • Hacker News Board

Re: Don't use Git rebase

#21

Post by format71 » Sat, Sep 16, 2017, 10:03 AM UTC

I like rebase. Because to me, git is more about communicating changes to other people than finding bugs. Just like testing is as much communicating intent to other developers as preventing new bugs.

So we rebase, and we merge with merge commits. This way, the developer are forced to resolve conflicts one by one on their own branch, instead of sorting out a huge pile in one go on a shared branch.

What I like about git, though, is that you can choose different approaches. Discuss in your team what you find important and use git to support that. If finding bugs with bisect is your main thing, use git in a way that makes that as easy as possible. If your have other needs, you'll have to find other ways of using the tool.

Learning and understanding the tool to use it in the best way to satisfy your needs.

Re: Don't use Git rebase

#22

Post by buserror » Sat, Sep 16, 2017, 10:03 AM UTC

fulafel wrote: post #18

pm215 wrote: post #17

Earlier quoted context omitted.

The major usecase I have for rebase is code review. If your code review stage happens at the point of merge/rebase/whatever into master, then rebase allows you to present the feature changes in a digestible way for the reviewers (split up into nice individual commits that make sense individually and are small enough to read and review without too much effort). The classic open source "send patches by email" workflow…

Ok, if your set of changes is too large to review in one piece, and you put in the work of refactoring your changes into a speedrun-style best possible history so they are cognitively review-friendly, I grant that this is a valid use case for rebase. Though erasing the real history is still a serious drawback, and the unit of code review is still too large. Not many projects work like this, however.

You don't have to erase the whole history, just duplicate it.

What we do is to have a developement branch, with the real history. When ready for merge/review, we duplicate that branch, rebase -i (on the same origin) to clean it all up without making any changes -- changes aren't allowed, only history split then merge the clean branch in the dev one (no conflicts: no changes!) and THEN ask for reviews on that clean branch.

If there are further changes, park the 'clean' branch, continue working on dev branch as before, and make any changes needed (typically we use the 'autosquash' naming convention), and re-do the cleanup before re-submitting.

Once the review is complete, just merge again devclean, and merge that in the trunk.

That way you have the whole history complete, and you also have a set of 'public' patches that have been reviewed and potentially can be upstreamed.

Re: Don't use Git rebase

#23

Post by blikdak » Sat, Sep 16, 2017, 10:06 AM UTC

Odd, I would rebase develop onto my feature, resolve conflicts which is easier as I'm dealing with my changes, then merge to eg develop. When time comes for integration I'd probably squash commit changes to the integration branch just to keep that a bit easier to track/undo, but preserve full history in my feature and develop branches do can revert specific commits etc. As always useful comments are a must so I disable automated merge commits.

Re: Don't use Git rebase

#24

Post by andrewaylett » Sat, Sep 16, 2017, 10:06 AM UTC

`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 setting yourself up for failure in the `git bisect` case: when you step back to find the source of an bug you're tracking down, the worst possible case is that you find it's introduced by a merge and not present in either of the parents. That's much more likely if your merge commits contain fix-ups of their own, which in turn is much more likely if you've got overlapping branches. If you rebase-and-merge then the merge won't have any extra changes, and if you rebase-and-fast-forward then you won't have any merge commits at all.

Re: Don't use Git rebase

#25

Post by jaeckel » Sat, Sep 16, 2017, 10:11 AM UTC

I liked the style of writing, but the lack of knowledge of the author made me create this account and adding my first hn comment.

Thanks to all others who explained technically what upset me so much.

Re: Don't use Git rebase

#26

Post by pm215 » Sat, Sep 16, 2017, 10:40 AM UTC

fulafel wrote: post #18

pm215 wrote: post #17

Earlier quoted context omitted.

The major usecase I have for rebase is code review. If your code review stage happens at the point of merge/rebase/whatever into master, then rebase allows you to present the feature changes in a digestible way for the reviewers (split up into nice individual commits that make sense individually and are small enough to read and review without too much effort). The classic open source "send patches by email" workflow…

Ok, if your set of changes is too large to review in one piece, and you put in the work of refactoring your changes into a speedrun-style best possible history so they are cognitively review-friendly, I grant that this is a valid use case for rebase. Though erasing the real history is still a serious drawback, and the unit of code review is still too large. Not many projects work like this, however.

My definition of "too large to review in one piece" is "more than 200-250 lines", so most non-trivial changes benefit in my view from being split into clean patchsets. It is extra effort that's purely to reduce the code review workload, so it makes most sense when the project is very short of code review resources and the reviewers aren't all the same small set of people as the coders (ie not all working for the same company). Keeping a clean set of commits gets easier with practice though, especially if you do it as you go along rather than trying to do it all at the end. I like stgit for tooling that allows you to think of your branch as a stack of patches and avoid the horrible UI of raw git rebase.

Re: Don't use Git rebase

#27

Post by hashhar » Sat, Sep 16, 2017, 10:42 AM UTC

shock wrote: post #19

> Graphs of non-linear history, “train tracks”, can be intimidating. They certainly felt that way to me to begin with, but there’s no reason to be scared of them. There are many magnificent tools that can analyse and visualise complex Git history, both GUI- and CLI-based. It's a pity the author doesn't mention some of those magnificent tools. Some tools I know/use: CLI: tig GUI: gitg, qgit (Linux) Any others?

If you use VSCode, there's a great extension called GitLens and GitHistory Log. The combination of them makes browsing repository histories, resolving conflicts and tracking changes really easy and fast.

Re: Don't use Git rebase

#28

Post by mvc » Sat, Sep 16, 2017, 10:44 AM UTC

andybak wrote: post #9

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.

Surely our tools should simply have an option of hiding useless merges. It's a display problem not a reason to change history.

They do. git log --no-merges

Re: Don't use Git rebase

#29

Post by Vinnl » Sat, Sep 16, 2017, 10:49 AM UTC

fulafel wrote: post #2

What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing. Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity…

There's no such thing as "real" history - you don't commit every line of code you add or remove, or even every character. Rather, you choose some points in time to commit.

For me, those are often arbitrary - I can't get something to work at a certain point, so I make a WIP commit with the buggy work at that point, and will come back to it the next day.

Before I merge my branch back into master, though, I want my commit history to be useful. "This is the point where I went home or was disturbed that day" is not useful to future developers. "This is the work I did on this individual feature and everything that's needed to run it and to have the tests succeed is in this commit, and this was the reasoning behind what I did", however, is.

In other words, I rebase to divide my codebase into non-arbitrary units of code, not based on chronology, but on what is useful together.

Re: Don't use Git rebase

#30

Post by pletnes » Sat, Sep 16, 2017, 10:51 AM UTC

At least part of the arguments against rebase are arguments for feature branches. Keep master forever and rebase your feature/bug branches, I would rather say. E.g bitbucket has features for this too - prohibit force push on master/release branches, allow on dev branches.