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

Git rebase, what can go wrong

jvns.ca

Post reply on HN
Print view View original

71–80 of 404 posts

Re: Git rebase, what can go wrong

#71

Post by naasking »

paulddraper wrote: post #21
davedx wrote: post #9

I’ve never understood the tradeoff of rebasing, squashing or otherwise “keeping a clean history”. It always seemed like tons of sometimes highly error prone work (sometimes you can wipe out a colleague’s work with it! Wtf!), for almost no gain (why does it matter that the git history is “clean”?).

> keeping a clean history This being a principal reason for VCS, I very much understand the motivation.

"Clean history" is not a principal reason for VCS. "Full history so you don't accidentally lose something and can revert to any point" is the principal reason. When "clean history" conflicts with "full history", the choice should always defer to the latter. Rebase clearly breaks the full history principle.

Re: Git rebase, what can go wrong

#72

Post by WirelessGigabit »

mablopoule wrote: post #13
recursive wrote: post #5

Earlier quoted context omitted.

Squash merges cut down the noise considerably.

I actually hate squash merge because of all the noise it adds. Sure, the commit graph looks nicer, but it come with a terrible loss of information when doing git blame. I'm a big proponent of rebase and squash if it helps to make a commit more coherent, but we use squash merges by default in the current project I'm working on, and I die a little bit each time I try to understand what changes were related to a line wh…

Me too. I care a LOT about provenance. And squash merge completely breaks that.

When my branch is up to date with `main` I can build an artifact, fast forward merge that branch into `main` and RETAIN the artifact, and merely update its tags to mark it as `merged` in.

With a squash I lose that information.

Now, GitHub does not allow me to do a fast-forward merge but I can still trace the 2 commits that are the parent of the resultant merge, and find the artifact based on that, and retag.

Re: Git rebase, what can go wrong

#73

Post by btilly »

diek wrote: post #67
btilly wrote: post #48

Earlier quoted context omitted.

There is a giant benefit to it being messy. And that is that the mess is the actual history. Every time you do a git rebase, you are literally asking your source control system to lie about history. If you mess up, and you eventually will, you're then forced to manually figure out what the history really was despite being lied to. If you mess it up, well, good luck. I used to work at a company where someone (we never…

The golden rule is "do not rewrite history of a public branch". Rebase/squash your PR branches to your heart's content, but once it's merged that's it. You get clean history by not merging branches with 50 intermediary "fiddling with X" commits in them.

Related, it is a bad idea to use long-running per team branches. Merge early, merge often, get commits to trunk ASAP. With best practices on unit testing, code review, and so on, this scales to many thousands of developers. And will save a lot of pain over time.

Re: Git rebase, what can go wrong

#74

Post by ender341341 »

gus_massa wrote: post #65

> undoing a rebase is hard I do a lot of rebases, but they are trivial rebases in a feature branch, like changing the order of new features and fixups, and then squashing the fixups to make a nice PR. Don't try to do smart weird rebases!!! From time to time I have to make a smart weird rebase because my small commits order is just a mess, or I have to split a commit or something unusual. The important first step is t…

> Don't try to do smart weird rebases!!!

If I need to do a non-trivial rebase I always start by creating a backup branch so I can delete my fuck up and start over trivially, which was a hard learned lesson.

Re: Git rebase, what can go wrong

#75

Post by gorjusborg »

h1fra wrote: post #3

I might be lucky but in my whole developer life I have only used like 3 commands git stash, git pull --rebase and git merge. I'm not even sure I used git rebase once.

Sure, there are situations when you can get by without rebase. I would even say 'stay away from rebase if you do not have a solid understanding of what it does'.

However, life is much better with rebase than without it.

Re: Git rebase, what can go wrong

#76

Post by gray_-_wolf »

nerdponx wrote: post #16
mablopoule wrote: post #13

Earlier quoted context omitted.

I actually hate squash merge because of all the noise it adds. Sure, the commit graph looks nicer, but it come with a terrible loss of information when doing git blame. I'm a big proponent of rebase and squash if it helps to make a commit more coherent, but we use squash merges by default in the current project I'm working on, and I die a little bit each time I try to understand what changes were related to a line wh…

This is the big one for me. destroying Commit information just to keep the graph tidy is a bad idea in my opinion. It would be better if Git provided better tools for filtering the log, e.g. providing some mechanism to elide commits from parents of any merge commit other than the 1st.

You mean like for example `git log --first-parent`?

Re: Git rebase, what can go wrong

#77

Post by anonyme-honteux »

AndrewDucker wrote: post #70

I find it fascinating that people talk about "Having a history of what people did" in such emotive terms - "Cluttering", "Polluting". What matters is that you end up with working systems. That a lot of change happened is just, well, what happened. It doesn't need to be prettied up and made to look like your development occurred in a clockwork march of cleanliness. It literally does not matter unless you spend a lot o…

It’s ego

Re: Git rebase, what can go wrong

#78

Post by debaserab2 »

btilly wrote: post #48
ajkjk wrote: post #12

Earlier quoted context omitted.

Never understood why you wouldn't want it clean. There's no benefit whatsoever to it being messy and it's a liability for a lot of reasons, whereas the clean version is free and easy and makes everything you do that interacts with git history simpler.

There is a giant benefit to it being messy. And that is that the mess is the actual history. Every time you do a git rebase, you are literally asking your source control system to lie about history. If you mess up, and you eventually will, you're then forced to manually figure out what the history really was despite being lied to. If you mess it up, well, good luck. I used to work at a company where someone (we never…

> I used to work at a company where someone (we never figured out who)

Wouldn't this be trivially solvable by git bisecting your deploy branch?

Re: Git rebase, what can go wrong

#79

Post by lelandfe »

diek wrote: post #63
nerdponx wrote: post #16

Earlier quoted context omitted.

This is the big one for me. destroying Commit information just to keep the graph tidy is a bad idea in my opinion. It would be better if Git provided better tools for filtering the log, e.g. providing some mechanism to elide commits from parents of any merge commit other than the 1st.

> destroying Commit information just to keep the graph tidy is a bad idea in my opinion The commit information I see when telling teams to squash their branches on merge is not valuable. * "fixing whitespace" * "incorporate review comments" * "fix broken test" * "fix other broken test" (note, the broken tests were broken by the changes in the PR) As soon as that PR is merged those commits are worthless. And there are…

Those commits would be the bathwater one casts out alongside the useful commits in using squash merges.

Re: Git rebase, what can go wrong

#80

Post by naasking »

jzm2k wrote: post #58
m3kw9 wrote: post #20

Git rebase is stupid, I’ve seen countless f ups because someone needed the git history to look good

git-rebase is stupid because somebody doesn't know how to use it? I use it all the time and I really like how I can make garbage commits (wip, test) and then squash them into atomic commits which are easy to review and later on easy to bisect when inevitably mistakes happen. Sure I've fucked up too when I was learning on how to use it and those were some painful mistakes but only through using it and making those mis…

> git-rebase is stupid because somebody doesn't know how to use it?

The whole purpose of source control is to reliably track code changes so you don't lose anything and can revert to any point or recover from bad merges. Since rebase permits you to violate this core purpose and literally lose the entire history of code changes, then yes, it is stupid.

Post reply on HN