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

Git Rebase for the Terrified

brethorsting.com

Post reply on HN
Print view View original

251–260 of 305 posts

Re: Git Rebase for the Terrified

#251

Post by yowlingcat »

Groxx wrote: post #246

I also get tons of mileage out of This One Weird Trick: make a new branch first. Every single time it appears non-trivial, just abort and branch before continuing. Then if you screw up, even several steps later when it's hard to un-rebase a portion, you just go back to the original . No need to dig through the ever-confusing reflog format, just use branches. For really gnarly ones, it also means you can early compare…

This is the way. Branches are structurally cheap in git for a reason - to make it easy to do this! The only minor pain is that then I have to remember to clean up the unused branches for paths that didn't pan out but that isn't so bad anyways and helps me make sense of/remind me of what didn't work as I was trying to solve something.

Re: Git Rebase for the Terrified

#252

Post by DenisM »

nothrabannosir wrote: post #101
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…

Debugging from git history is a separate question from merge vs rebase. Debugging from history can be done with non-rebased merges, with rebased merges, and with squashed commits, without any noticeable difference. Pass `--first-parent` to git-log and git-bisect in the first two cases and it's virtually identical. My preference for rebasing comes from delivering stacked PRs: when you're working on a chain of individu…

If you have not already, try Graphite. You will be delighted as it serves that exact purpose.

Re: Git Rebase for the Terrified

#253

Post by tunesmith »

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 love rebase locally, especially when I have a few non-urgent branches that sit around for a little while. I hate rebase after pushing. The rule of thumb that has worked for me is "don't rewrite someone else's history". Rewriting origin's history is not so bad, but if there's even a chance that a team member has pulled, or based work off your pushed branch (ugh), rebase is horrible.

Re: Git Rebase for the Terrified

#254

Post by Groxx »

yowlingcat wrote: post #251
Groxx wrote: post #246

I also get tons of mileage out of This One Weird Trick: make a new branch first. Every single time it appears non-trivial, just abort and branch before continuing. Then if you screw up, even several steps later when it's hard to un-rebase a portion, you just go back to the original . No need to dig through the ever-confusing reflog format, just use branches. For really gnarly ones, it also means you can early compare…

This is the way. Branches are structurally cheap in git for a reason - to make it easy to do this! The only minor pain is that then I have to remember to clean up the unused branches for paths that didn't pan out but that isn't so bad anyways and helps me make sense of/remind me of what didn't work as I was trying to solve something.

branch-rebase-3-final_2_DO-NOT-EDIT---IN-PROD-incident_93473672

The struggle is real.

I generally have a "show branches by age" script to help that a bit

Re: Git Rebase for the Terrified

#255

Post by DenisM »

I found it a lot safer to cherry pick into a new temp branch, test things out, rename the old branch to an archive name, and rename the new temp branch to old name.

That is until I started using graphite, that solved the problem completely for me. The only trick is to never mix graphite and git history editing.

Re: Git Rebase for the Terrified

#256

Post by cmrdporcupine »

drysine wrote: post #216
Yeroc wrote: post #208

Earlier quoted context omitted.

Most of those 10 squashed commits likely had commit comments like: "Cleanup based on PR feedback." etc.

That's what --amend and --fixup are for.

Which wreaks havoc with githubs shitty code review tool.

Which is an argument against GitHub, not clean commit history

Re: Git Rebase for the Terrified

#257

Post by nothrabannosir »

DenisM wrote: post #252
nothrabannosir wrote: post #101

Earlier quoted context omitted.

Debugging from git history is a separate question from merge vs rebase. Debugging from history can be done with non-rebased merges, with rebased merges, and with squashed commits, without any noticeable difference. Pass `--first-parent` to git-log and git-bisect in the first two cases and it's virtually identical. My preference for rebasing comes from delivering stacked PRs: when you're working on a chain of individu…

If you have not already, try Graphite. You will be delighted as it serves that exact purpose.

I use magit which afaik is still undefeated for this workflow. Particularly with this snippet to “pop down” individual ranges of changes from a commit: https://br0g.0brg.net/notes/2026-01-13T09:49:00-0500.html .

Re: Git Rebase for the Terrified

#258

Post by stouset »

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…

The comments sections in git posts vs. jj posts are always hysterical to me.

If there’s a jj post on HN, people come out of the woodworks to say that git is easy and it’s crazy to suggest that anyone finds it difficult or confusing. Also people saying they’ve figured out git is super usable if you only ever use commit, merge, pull.

Then you have git posts where everyone talks about how hard some basic things are, how easy it is to mess up your repo, how frustrating rebase is, etc.

It’s fun to watch.

Re: Git Rebase for the Terrified

#259

Post by hambes »

To add to the very short "valodating the result" section, let me recommend `git range-diff`.

Range diff takes two commit ranges and compares thor commits pairwise, wich is perfect for rebases, since after the rebase all commits still exist and should be mostly identical, just at some other place in the history.

Use it like `git range-diff main..origin/mybranch main..mybranch` to compare the local, rebased branch with the upstream branch.

This let's you easily verify that eitger mothing changed or that any conflicts were resolved well.

Re: Git Rebase for the Terrified

#260

Post by stouset »

sigseg1v wrote: post #77
fc417fc802 wrote: post #55

Earlier quoted context omitted.

> Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying From your link. The actual issue that people ought to be discussing in this comment section imo.

THIS is the hill I will die on. Why do we advocate destroying information/data about the dev process when in reality we need to solve a UI/display issue? The amount of times in the last 15ish years I've solved something by looking back at the history and piecing together what happened (eg. refactor from A to B as part of a PR, then tweak B to eventually become C before getting it merged, but where there are important…

Because nobody cares about the dev process. The number of times I’ve looked back in the history and seen a branch with a series of twenty commits labeled “fix thing”, “oops”, “typo”, “remove thing I tried that didn’t work”, or just a chain of WIP WIP WIP WIP is useless, irritating, and pointless.

One commit per logical change. One merge per larger conceptual change. I will rewrite my actual dev process so that individual commits can be reviewed as small, independent PRs when possible, and so that bigger PRs can be reviewed commit-by-commit to understand the whole. Because I care about my reviewers, and because I want to review code like this.

Care about your goddamn craft, even just a little bit.

Post reply on HN