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

31–40 of 88 posts

Re: Don't use Git rebase

#31

Post by ajdlinux »

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?

Regular old gitk is one of the few tools that I find performant-enough to use on the Linux kernel tree.

Re: Don't use Git rebase

#32

Post by ddevault »

There's a more nuanced approach to git rebase. You should use it the other way around - switch to your feature branch and `git rebase master` to update your branch and resolve conflicts. Then test it and `git merge`. I also use git rebase to tidy up the branch's history - generally not entirely squashing it, though.

Re: Don't use Git rebase

#33

Post by humanrebar »

narsil wrote: post #11

In addition to squashing commits, you can merge with `--no-ff` to create s merge commit and semi-linear history showing when new code arrived.

This should be getting more attention. From the perspective of the master branch, it has the benefits of squashed merges without losing your commit history.

I'll often have a patch that has a few things going on:

1. Refactor code in one file

2. Fix a bug in another module uncovered by the newly refactored code (maybe a code path that hasn't been hit until now)

3. Some quick fixes made while I was looking at that code

...if I made a mistake in step 1, it's likely that step 2, step 3, or both would be useful to keep. If it's squashed and merged, it may be difficult to undo just step 1. And it's good communication to keep each as their own commit because each is its own atomic change.

And I can always squash things myself as I feel the need.

Re: Don't use Git rebase

#34

Post by OJFord »

> Consider the case where a dependency that is still in use on feature has been removed on master. When featureis being rebased onto master, the first re-applied commit will break your build, but as long as there are no merge conflicts, the rebase process will continue uninterrupted. The error from the first commit will remain present in all subsequent commits, resulting in a chain of broken commits.

Easy, just fixup the commit that (re)introduced the dependency.

> You pretend that the commits were written today, when they were in fact written yesterday,

The author and committer dates will differ accordingly.

Re: Don't use Git rebase

#35

Post by tekacs »

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?

For Mac users, there's http://gitup.co/ (I'm not affiliated and it's FOSS).

GitUp is beautiful, incredibly fast and you operate directly on the (well laid-out) graph for almost everything, so you're always acutely aware of the commit history.

(I mostly use Windows + Linux at the moment and this is probably the piece of software I miss the most, even though I prefer shell for absolutely everything else)

Re: Don't use Git rebase

#36

Post by reledi »

This seems like a knee jerk reaction because a co-worker's sloppy rebase caused you to waste a day.

This highlights a bigger issue, many people don't learn their tools well enough.

I've been teaching my fellow senior engineers how to use git the last six months because they've only been using git GUIs until then. They're terrified of merge conflicts and they often make mistakes fixing them.

I'd rather educate people and let them make their own decisions once they can understand and justify the tradeoffs.

Re: Don't use Git rebase

#37

Post by smackay »

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.

On a given feature branch the history is only important if there is more than one review until the work is complete. What the developer does in between these visible/public events is almost always not important. For example in a "make work, make right" situation where the original work is thrown away and rewritten you definitely are not interested in the history.

Re: Don't use Git rebase

#38

Post by he0001 »

Vinnl wrote: post #29
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 comm…

Well, assuming that you are adding features in parallel you have an history. You have a branch with feature A and are about to build feature B, which is now based on A, someone else is building feature C which is also based on A. Building B and C might require different or equal changes to A.

There's no guarantee that any of these features will be built in order since they might have different priorities, difficulties or level of acceptance so it's hard to tell which one must or will be done in what order. Rebasing pretty much settles that while merging is much more sane to that workflow. It's harder to keep it functional yes, but it's enabling parallel development. Using rebasing and/or merge isn't a source control problem but a feature management problem.

Re: Don't use Git rebase

#39

Post by baq »

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.

Nothing is lost if there's no information there in the first place.

Re: Don't use Git rebase

#40

Post by icek »

reledi wrote: post #36

This seems like a knee jerk reaction because a co-worker's sloppy rebase caused you to waste a day. This highlights a bigger issue, many people don't learn their tools well enough. I've been teaching my fellow senior engineers how to use git the last six months because they've only been using git GUIs until then. They're terrified of merge conflicts and they often make mistakes fixing them. I'd rather educate people…

Merge conflicts, history readability, and PR readability are just the things that rebase helps with. I understand, I have coworkers who said "keep things simple; you shouldn't have to be an expert in VCS" as if learning how to use your tools is a bad thing! It's not like Git even takes that long to master.
Post reply on HN