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

211–220 of 305 posts

Re: Git Rebase for the Terrified

#211

Post by douglee650 »

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…

Isn't it more of a style decision where if your team rebases, and practices clean code discipline, and excellence is a habit rather than an enforcement — the signals visibly emit in `status`.

Most committers don't really understand remotes, much less rebasing.

Re: Git Rebase for the Terrified

#212

Post by xorcist »

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…

> cp -r $original-repo $new-test-repo

This is almost exactly what git does, except it's a million times faster. Every commit is one of those copies, and you can instantly jump to any one of them using git checkout.

If you like this mental model, you'll feel right at home with git. You will love git reflog.

Re: Git Rebase for the Terrified

#213

Post by [deleted] »

mr_mitm wrote: post #45
thibaut_barrere wrote: post #4

PSA: I’m not terrified of rebase, yet it’s good to know this: https://docs.github.com/en/get-started/using-git/about-git-r... > Warning - Because changing your commit history can make things difficult for everyone else using the repository, it's considered bad practice to rebase commits when you've already pushed to a repository. A similar warning is in Atlassian docs.

Is there a reason why that recommendation cannot be changed to "don't ever force push unless you are certain no one else has fetched this branch"?

[deleted]

Re: Git Rebase for the Terrified

#214

Post by xorcist »

magicalhippo wrote: post #178
WolfeReader wrote: post #169

Earlier quoted context omitted.

Please tell me you are using Git-SVN or Hg-SVN. Using bare SVN as a client hasn't been necessary in over a decade.

Using SmartSVN which makes life a fair bit better but still keeps this confusing terminology. We'll be migrating to Git this year though so. For reference, the codebase is over 20 years old, and includes binary dependencies like libraries. Makes it easy to compile old versions when needed, not so easy on the repository size...

That terminology is identical in git, likely inspired by cvs and svn, so that bit probably won't improve.

It's inherently confusing to juggle different trees, and clearly you need some terminology for it. At least this one has become a bit of a standard.

Re: Git Rebase for the Terrified

#215

Post by literallyroy »

throwaway7783 wrote: post #166

I avoid rebase like plague (perhaps because of my early experiences with it). I used to get continuous conflicts for the same commits again and again, and the store and replay kinda helped with it but not always. Merge always worked for me (once I resolve conflicts, thats the end of it). Now I always merge main into my feature branch and then merge it back to main when ready. Does it pollute the history? Maybe, but I…

I think the callout to squash first will be helpful (if your lots of commits aren’t good info themselves)

Re: Git Rebase for the Terrified

#216

Post by drysine »

Yeroc wrote: post #208
drysine wrote: post #195

Earlier quoted context omitted.

>each commit nominally should work Except it can be the result of 10 squashed commits.

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.

Re: Git Rebase for the Terrified

#217

Post by mrkeen »

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…

Any time I'm doing anything remotely to do with merging, I use 'git diff' or 'git difftool'.

If I diff against master, I see changes in 300+ files, when I've only changed 5 (because other people have changed 300+ files.)

> Fundamentally, I do not debug off git history.

Neither. The usual argument I hear against rebase is that it destroys history. Since I don't debug off git history, I'm quite happy to destroy it, and get back to diffing my 5-file changes against (current) master.

Re: Git Rebase for the Terrified

#219

Post by MrDarcy »

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…

Two very useful use cases for rebase: 1) rewrite history to organize the change list clearly. 2) stacked pull requests of arbitrary depth.

You’ve never run a bisect to identify which commit introduced a specific behavior?

This is when I’ve found it most useful. Having commits merged instead of squashed narrows down and highlights the root problem.

It’s a rare enough situation I don’t push for merge commits over squashed rebases because it’s not worth it, but when I have had to bisect and the commits are merged instead of squashed it is very very useful.

Those commit authors are who I noted as clear thinkers and have tracked over my career to great benefit.

Post reply on HN