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

91–100 of 305 posts

Re: Git Rebase for the Terrified

#91

Post by OptionOfT »

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.

Re: Git Rebase for the Terrified

#92

Post by Myrmornis »

> the worst case scenario for a rebase gone wrong is that you delete your local clone and start over. That’s it. Your remote fork still exists.

This is absolute nonsense. You commit your work, and make a "backup" branch pointing at the same commit as your branch. The worst case is you reset back to your backup.

Re: Git Rebase for the Terrified

#93

Post by dcre »

In about 12 years of using git (jj user now) I almost never rebased through the CLI, but I found shuffling branches around in a GUI pretty intuitive. I liked GitUp[0], which gave me undo way before jj existed.

The common view that a Git GUI is a crutch is very wrong, even pernicious. To me it is the CLI that is a disruptive mediation, whereas in a GUI you can see and manipulate the DAG directly.

Obligatory jj plug: before jj, I would have agreed with the top comment[1] that rebasing was mostly unnecessary, even though I was doing it in GitUp pretty frequently — I didn't think of it as rebasing because it was so natural. Now that I use jj I see that the cost-benefit analysis around git rebase is dominated by the fact that both rebasing and conflict resolution in git are a pain in the ass, which means the benefit has to be very high to compensate. In jj they cost much less, so the neatness benefit can be quite small and still be worth it. Add on the fact that Claude Code can handle it all for you and the cost is down to zero.

[0]: https://gitup.co/

[1]: https://news.ycombinator.com/item?id=46602056

Re: Git Rebase for the Terrified

#95

Post by game_the0ry »

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.

> That way the PR is the single unit of work.

Well if I have a diff of the PR with just the changes, then the PR is already a "unit of work," regardless of merge or rebase, right?

Re: Git Rebase for the Terrified

#96

Post by lanyard-textile »

Izkata wrote: post #79
echelon wrote: post #5

Earlier quoted context omitted.

git rebase squash as a single commit on a single main branch is the one true way. I know a lot of people want to maintain the history of each PR, but you won't need it in your VCS. You should always be able to roll back main to a real state. Having incremental commits between two working stages creates more confusion during incidents. If you need to consult the work history of transient commits, that can live in your…

> I know a lot of people want to maintain the history of each PR, but you won't need it in your VCS. Having worked on a maintenance team for years, this is just wrong. You don't know what someone will or won't need in the future. Those individual commits have had extra context that have been a massive help for me all sorts of times. I'm fine with manually squashing individual "fix typo"-style commits, but just squash…

Disagree!

If those commits were ready for production, they would have been merged. ;)

Don't put a commit on main unless I can roll back to it.

Re: Git Rebase for the Terrified

#97

Post by dcre »

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 is the post that made jj click for me, and not coincidentally it is about a rebase operation that feels complicated in git but trivial in jj.

https://lottia.net/notes/0013-git-jujutsu-miniature.html

Re: Git Rebase for the Terrified

#98

Post by Marsymars »

CJefferson wrote: post #56
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 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" and "Update to async methods without locking", but I don't know that reviewers and future code readers are better served by that.

Re: Git Rebase for the Terrified

#99

Post by any1 »

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…

> Fundamentally, I do not debug off git history.

Are you saying that you've never used git bisect? If that's the case, I think you're missing out.

Re: Git Rebase for the Terrified

#100

Post by hnben »

skipkey wrote: post #84
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 can give you an example of when I am glad I rebased. There have been many times I have been working on a feature that was going to take some time to finish. In that case my general workflow is to rebase against main every day or two. It lets me keep track of changes and handle conflicts early and makes the eventual merge much simpler. As for debugging I’ve never personally had to do this, but I imagine git bisect w…

> I can give you an example of when I am glad I rebased

I think the question was about situations where you were glad to rebase, when you could have merged instead

Post reply on HN