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

131–140 of 305 posts

Re: Git Rebase for the Terrified

#131

Post by z3dd »

embedding-shape wrote: post #17

> The response is often hesitation or outright fear. I get it. Rebase has a reputation for destroying work, and the warnings you see online don’t help. The best method for stop being terrified of destructive operations in git when I first learned it, was literally "cp -r $original-repo $new-test-repo && go-to-town". Don't know what will happen when you run `git checkout -- $file` or whatever? Copy the entire director…

why copy anything at all? you just need to preserve the head and that's it. As simple as `git branch bkp` and that's all.

Re: Git Rebase for the Terrified

#132

Post by recursive »

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.

I've used git bisect on a repo whose commit graph is at least 20-wide at some points. In the two cases I used it, it identified the individual commit. I didn't think very hard about it. It was the first time I used bisect. Maybe I got lucky.

Re: Git Rebase for the Terrified

#133

Post by gwking »

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…

This may be outdated because git’s defaults have improved a lot over the years. When I first used git on a team was in 2011. As I recall, there were various commands like git log -p that would show nothing for a merge commit. So without extra knowledge of the git flags you would not find what you were looking for if it was in a side path of the merge history. This caused a lot of confusion at times. We switched to a rebase approach because linear history is easier for people to use.

To answer your question directly, if somewhat glibly, I’m glad I rebased every time I go looking for something in the history because I don’t have to think about the history as a graph. It’s easier.

More to your point, there are times when blame on a line does not show the culprit. If you move code, or do anything else to that line, then you have to keep searching. Sometimes it’s easier to look at the entire patch history of a file. If there is a way to repeatedly/recursively blame on a line, that’s cool and I’d love to know about it.

I now manage two junior engineers and I insist that they squash and rebase their work. I’ve seen what happens if they don’t. The merges get tangled and crazy, they include stuff from other branches they didn’t mean to, etc. the squash/rebase flow has been a way to make them responsible for what they put into the history, in a way that is simple enough that they got up to speed and own it.

Re: Git Rebase for the Terrified

#134

Post by Aperocky »

kps wrote: post #72
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…

And `jj undo`, so nothing is terrifying.

well git reflog is that, annoying, yes, but we have LLM so I don't actually need to remember how all the command syntax exactly like back in 2019.

Re: Git Rebase for the Terrified

#135

Post by seba_dos1 »

rich_sasha wrote: post #67
nh2 wrote: post #62

Earlier quoted context omitted.

The reflog is not a git internal -- it is your local repository's "true history", including all operations that you ran. The `git log` history that you push is just that curated specific view into what you did that you wish to share with others outside of your own local repository. The reflog is to git what Ctrl+Z is to Microsoft Word. Saying you don't want to use the reflog to undo a rebase is a bit like saying you…

But it's at best much harder to find stuff in the reflog than to simply use git's history browsing tools. "What's the state of my never-rebased branch at time X" is a trivial question to answer. Undoing a rebase, at best, involves some hard resets or juggling commit hashes. None of it is impossible, but IMHO it's a lot of excitement of the wrong kind for essentially no reward.

> "What's the state of my never-rebased branch at time X" is a trivial question to answer.

Yes, but only because of reflog.

Re: Git Rebase for the Terrified

#136

Post by recursive »

tjpnz wrote: post #28
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 had recent interns who've struggled with rebase and they've never known anything but Git. Never understood why that was given they seem ok with basic commits and branching. I would agree that rebase is easier to reason about than merging yet I'm still needing to give what feels like a class on it.

The fact that people have a harder time understanding rebase is evidence that rebase is harder to reason about. Whether you update your understanding based on that evidence is up to you. If I have to pick between merge and rebase, I would generally pick merge. It seems to cause less conflicts with long-lived branches. Commits maintain their identity so each one has to be conflict-resolved at most once.

However, even better for me (and my team) is squash on PR resolve.

Re: Git Rebase for the Terrified

#137

Post by skulk »

_flux wrote: post #26
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…

I think I'd love to use Jujutsu, but I enjoy Magit (for Emacs) too much to entertain the thought of switching :/. Besides, Magit rebasing is also pretty sweet.

I used to think like this, but then I realized: jj-mode.el exists[0] and you can still use magic since it's still a git repo underneath. Seriously, don't let this hold you back.

[0]: https://github.com/bolivier/jj-mode.el

Re: Git Rebase for the Terrified

#138

Post by recursive »

z3dd wrote: post #131
embedding-shape wrote: post #17

> The response is often hesitation or outright fear. I get it. Rebase has a reputation for destroying work, and the warnings you see online don’t help. The best method for stop being terrified of destructive operations in git when I first learned it, was literally "cp -r $original-repo $new-test-repo && go-to-town". Don't know what will happen when you run `git checkout -- $file` or whatever? Copy the entire director…

why copy anything at all? you just need to preserve the head and that's it. As simple as `git branch bkp` and that's all.

In order for that to work you need some level of confidence that rebase doesn't mess with your branch. Rebase has a reputation for "rewriting history".

Re: Git Rebase for the Terrified

#139

Post by rpcope1 »

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 worked on several codebases where it was enforced that the commit be rebased off of whatever the main branch was, all units of work squashed to a single commit, and only "working" code be checked into the main branch. This gives you a really good linear history, and when you're disciplined about writing good final commit messages and tagging them to a ticket, it means bisecting to find challenging bugs later becomes tractable, as each commit nominally should work and should be ready to deploy for testing. I've personally solved a number of challenging regressions this way.

Re: Git Rebase for the Terrified

#140

Post by jefurii »

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 use `git rebase` all the time, along with `git add -p`, `git diff` and other tools. It helps me to maintain logical commit history.

- Reshuffle commits into a more logical order. - Edit commit subjects if I notice a mistake. - Squash (merge) commits. Often, for whatever reason pieces of a fix end up in separate commits and it's useful to collect and merge them.

I'd like to make every commit perfect the first time but I haven't managed to do that yet. git-rebase really helps me clean things up before pushing or merging a branch.

Post reply on HN