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

51–60 of 404 posts

Re: Git rebase, what can go wrong

#51

Post by heisenberg302 »

I prefer rebase over merge because when merging since the commits are added to HEAD, when I add new commits after merge, I find it harder to understand what is being added with the current pull request.

One thing that annoys people when rebasing is, if you need to rebase a couple of times and also you change the commit history of current branch, you might end up solving the same "conflicts". To avoid this, you can use git rerere, this basically saves your conflict resolution, and if the same conflict is encountered, it resolves it automatically: https://mirrors.edge.kernel.org/pub/software/scm/git/docs/gi...

Re: Git rebase, what can go wrong

#52

Post by btilly »

scintill76 wrote: post #24
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”?).

> sometimes you can wipe out a colleague’s work with it! Wtf! I’m not necessarily on Team Rebase, but isn't this just as likely with merging gone wrong?

Not nearly as badly.

A badly done merge can indeed ruin code. But you'll always have the versions that went into the merge, and the merge itself. Your history has all of the information to recreate exactly what happened, find what changed, and then figure out how to fix it.

A badly done rebase not only ruins your work, it also removes from the branch any record of your work having been done. Unless you can find the right stray old commit which is not yet cleaned up, there is no choice but to start doing it again from scratch.

Re: Git rebase, what can go wrong

#53

Post by brunooliv »

Haven't read the article yet. Whenever I'm working on a feature branch, I always tend to "merge master into the feature branch". The effect of this obviously being that I want to have the latest changes incorporated into my work to avoid conflicts and/or to proceed with my own feature work. This has always worked well for me and never failed me.

If I understand what rebase does correctly, it just adds all my commits in my remote feature branch to the HEAD of the branch that's being rebased onto. That's why after doing it and finishing it, one needs to do a push force because the head of the remote feature branch would diverge. But... Why? How is this better or different than just merging master into the branch? Gitlab for example and Intellij show all the branch changes and commits with their hashes so it all can be cherry picked or reverted if needed quite easily...

Has anybody who used to "merge master into" and now uses rebase that has a much different view on it being better?

Re: Git rebase, what can go wrong

#54

Post by sidlls »

dahart wrote: post #42
recursive wrote: post #5

Earlier quoted context omitted.

Squash merges cut down the noise considerably.

What I think I see these days is squash merges being used lazily to avoid having to do anything to build a clean history with clearly semantically delineated commits. Squash merges are good compared to an alternative where people check in super messy noisy branches, but they unfortunately have a big downside because squash merges can make bisecting and history spelunking more difficult, when the branches that are squ…

What is a "semantically delineated commit"? What is a "clean history"? Why are these two things important?

Re: Git rebase, what can go wrong

#55

Post by dataflow »

Since everyone is bringing up squashing...

There's a false dichotomy nobody addresses here, which is the notion that there needs to be such a thing as "the" history for you to get the benefits of a clean history.

If all you really want is a linear history, then just do merges, and make sure the "first parent" is the main branch (which you can enforce with tooling). Now you can just traverse solely the (linear!) sequence of first parents, which is exactly the same view squashing would have given you, except without the information loss.

If for some reason you can't stand the idea of something branching off your main branch at all, then set up a separate job that automatically squashes everything onto a branch that only it can write to (or branch from). Now you have a truly linear history with nothing branching off it, exactly as you would've had with squashing. And you can always reproduce it on demand.

That way you avoid the information loss, and can always do archeology on the full evolution graph if needed.

Re: Git rebase, what can go wrong

#56

Post by diek »

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…

> I die a little bit each time I try to understand what changes were related to a line when tracking down a bug

A change/feature/bug is a branch, which is squashed into a commit on your main branch, right? So your main branch should be a linear history of changes, one change per commit.

How does that impact the ability to git blame?

Re: Git rebase, what can go wrong

#57

Post by unicornmama »

ajkjk wrote: post #12
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”?).

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.

You can run ‘git log —-first-parent’ that will give you the same output as squash merging, without losing the ability to effectively manage stacked branches/PRs.

But because GitHub and other tool’s version of rendering history just flatten merge commits into spaghetti we’re stuck with squash merge. Thanks GitHub.

Re: Git rebase, what can go wrong

#58

Post by jzm2k »

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 mistakes have I learned to use the tool to great advantage (clean history).

Re: Git rebase, what can go wrong

#59

Post by mbakke »

ajkjk wrote: post #8

I love rebase (I'm a tip-of-master-only person, no merges ever, squash all your commits with `rebase -i` before pushing and write one good commit message for the group). But there's one really, really irritating thing about them: You should not be able to use `--amend` during a rebase. For me editing all my changes onto the commit I'm working on with `git commit -a --amend` (or as I've aliased it, `gcaa`) is automati…

I have a similar workflow, but make a bunch of commits with "git commit --fixup HEAD". (Or --squash REF).

Then on the final rebase the commits are automatically ordered with s and f as appropriate.

Although I do a fair bit of amending, too.

Re: Git rebase, what can go wrong

#60

Post by jihadjihad »

brunooliv wrote: post #53

Haven't read the article yet. Whenever I'm working on a feature branch, I always tend to "merge master into the feature branch". The effect of this obviously being that I want to have the latest changes incorporated into my work to avoid conflicts and/or to proceed with my own feature work. This has always worked well for me and never failed me. If I understand what rebase does correctly, it just adds all my commits…

Some people don't like having standalone merge commits that show up in the git history when merging master into feature
Post reply on HN