Git Rebase for the Terrified • Hacker News Board

Re: Git Rebase for the Terrified

#111

Post by magicalhippo » Tue, Jan 13, 2026, 4:03 PM UTC

spiffyk wrote: post #61

aeinbu wrote: post #57

> I always use VS Code for this step. Its merge conflict UI is the clearest I’ve found: it shows “Accept Current Change,” “Accept Incoming Change,” “Accept Both Changes,” and “Compare Changes” buttons right above each conflict. I still get confused by vscode’s changing the terms used by Git. «Current» vs «incoming» are not clear, and can be understood to mean two different things. - Is “current” what is on the branch…

Git's "ours"/"theirs" terminology is often confusing to newcomers, especially when from a certain (incorrect, but fairly common) point of view their meaning may appear to be swapped between merge and rebase. I think in an attempt to make the terminology less confusing UIs tend to reinvent it, but they always fail miserably, ending up with the same problem, just with slightly different words. This constant reinvention…

We use SVN at work and it's a nightmare there too, "mine" and "theirs" and whatnot. I frequently end up looking at historical versions just to verify which is which.

If I have a merge conflict I typically have to be very conscious about what was done in both versions, to make sure the combination works.

I wish for "working copy" and "from commit 1234 (branch xyz)" or something informative, rather than confusing catch-all terms.

Re: Git Rebase for the Terrified

#112

Post by phrotoma » Tue, Jan 13, 2026, 4:05 PM UTC

git rebase appears to be a random number generator to me. I've got two PRs in flight, I realize that one branch requires something I did in the other branch. I go merge branch one, then rebase branch two off main. Half the time; success, get on with my day. The other half of the time; anarchy, madness, dogs and cats living together.

I remain terrified.

Re: Git Rebase for the Terrified

#113

Post by eeperson » Tue, Jan 13, 2026, 4:07 PM UTC

coffeebeqn wrote: post #2

I wish rebase was taught as the default - I blame the older inferior version control software. It’s honestly easier to reason about a rebase than a merge since it’s so linear. Understanding of local versus origin branch is also missing or mystical to a lot of people and it’s what gives you confidence to mess around and find things out

I've heard people say before that it is easier to reason about a linear history, but I can't a think of a situation where this would let me solve a problem easier. All I can think of is a lot of downsides. Can you give an example where it helps?

Re: Git Rebase for the Terrified

#114

Post by DarkNova6 » Tue, Jan 13, 2026, 4:07 PM UTC

708145_ wrote: post #39

I see no need to ever rebase manually, just merge on your branch and always fast-forward squash merge (only sane default) with GitHub/GitLab/whatever.

I don't see how this is not the first answer. What tools does everybody else work with??

Re: Git Rebase for the Terrified

#115

Post by tcoff91 » Tue, Jan 13, 2026, 4:08 PM UTC

simonw wrote: post #108

game_the0ry wrote: post #78

I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…

Do you ever use git bisect? I like to keep a linear history mainly so I don't have to think very hard about tools like that.

--first-parent with bisect really helps when the history is messy.

Re: Git Rebase for the Terrified

#116

Post by yawaramin » Tue, Jan 13, 2026, 4:08 PM UTC

OptionOfT wrote: post #91

game_the0ry wrote: post #78

I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…

In fact, for searching how a file got to the state it is I prefer that when PRs are merged, they are merged and not rebased. I want the commit shas to be the same. Rebasing on main loses provenance. If you want a clean history doing it in the PR, before merging it. That way the PR is the single unit of work.

Merging a PR with rebase doesn't lose provenance. You can just keep all the commits in the PR branch. But even if you squash the branch into a single commit and merge (which these tools automate and many people do), it still doesn't lose provenance. The provenance is the PR itself. The PR is connected to a work item in the ticketing system. The git history preserves all the relevant info.

Re: Git Rebase for the Terrified

#117

Post by tcoff91 » Tue, Jan 13, 2026, 4:08 PM UTC

grokys wrote: post #109

xlii wrote: post #11

Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers will hate 8 small PRs that are chained together ;-)) but it's also more consistent than git and works perfectly well as a drop-in replacement. In fact, I've been using Jujutsu for ~2 years as a drop-in and nobody complained (outside of the 8 small PRs chained t…

Does it support submodules yet? That was the thing that stopped me using it last time I checked.

Submodules are cursed. I feel bad for you that you have to work in a repo that uses them.

Re: Git Rebase for the Terrified

#118

Post by yawaramin » Tue, Jan 13, 2026, 4:09 PM UTC

xlii wrote: post #11

Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers will hate 8 small PRs that are chained together ;-)) but it's also more consistent than git and works perfectly well as a drop-in replacement. In fact, I've been using Jujutsu for ~2 years as a drop-in and nobody complained (outside of the 8 small PRs chained t…

> reviewers will love you, peers will hate 8 small PRs that are chained together

My peers are my reviewers...

Re: Git Rebase for the Terrified

#119

Post by wonger_ » Tue, Jan 13, 2026, 4:17 PM UTC

Marsymars wrote: post #98

CJefferson wrote: post #56

Earlier quoted context omitted.

I don't mind rebasing a single commit, but I hate it when people rebase a list of commits, because that makes commits which never existed before, have probably never been tested, and generally never will be. I've had failures while git bisecting, hitting commits that clearly never compiled, because I'm probably the first person to ever check them out.

Sometimes it feels like the least-bad alternative. e.g. I'm currently working on a substantial framework upgrade to a project - I've pulled every dependency/blocker out that could be done on its own and made separate PRs for them, but I'm still left with a number of logically independent commits that by their nature will not compile on their own. I could squash e.g. "Update core framework", "Fix for new syntax rules"…

I wonder how relevant and feasible this workflow would be: https://graydon2.dreamwidth.org/1597.html

Where you have two repositories, one "polished" where every commit always passes, and another for messier dev history.

Re: Git Rebase for the Terrified

#120

Post by tsimionescu » Tue, Jan 13, 2026, 4:25 PM UTC

game_the0ry wrote: post #78

I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…

I have often been happy to have a clean linear history when asking myself things like "does build X.Y.Z include this buggy change I found in commit abcdefg?". With a history full of merges, where a commit from 1st of January might be merged only on the 20th of July, this gets MUCH harder to answer.

This is especially true if you have multiple repos and builds from each one, such that you can't just checkout the commit for build X.Y.Z and easily check if the code contains that or not (you'd have to track through dependency builds, checkout those other dependencies, possibly repeat for multiple levels). If the date of a commit always reflects the date it made it into the common branch, a quick git log can tell you the basic info a lot of the time.