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

171–180 of 305 posts

Re: Git Rebase for the Terrified

#171

Post by WolfeReader »

thunderbong wrote: post #52
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…

One of the many things I like about fossil is the 'undo' command [0]. Also, since you can choose to keep the fossil repo in a separate directory, that's an additional space saver. [0] https://www3.fossil-scm.org/home/help/undo

Fossil is great.

Re: Git Rebase for the Terrified

#172

Post by bkmq »

tcoff91 wrote: post #117
grokys wrote: post #109

Earlier quoted context omitted.

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.

What is the problem with submodules? I like to use them because it means the code I need from another repo remains the same until I update it. No unexpected breaking changes.

Re: Git Rebase for the Terrified

#173

Post by layer8 »

PaulDavisThe1st wrote: post #151
DHRicoF wrote: post #142

Earlier quoted context omitted.

Then is not rebase your problem, but all your other practices. Long lived feature branches with lot's of unorganized commits with low cohesion. Sometimes it's ok to work like this, but you asking git not being judgamental is like saying your roomba should accomodate to you didin't asking you to empty it's dust bag.

You can make long lived feature branches work with rebase, you just have to regularly rebase along the way. I had a branch that lived for more than a year, ended up with 800+ commits on it. I rebased along the way, and the predictably the final merge was smooth and easy.

I don’t see how rebase frequency changes the problem of getting conflicts with some random commit within your long-lived branch, when doing a rebase.

I rebase often myself, but I don’t understand the logic here.

Re: Git Rebase for the Terrified

#174

Post by quacker »

Rebasing replays your commits on top of the current main branch, as if you’d just created your branch today. The result is a clean, linear history that’s easier to review and bisect when tracking down bugs.

The article discusses why contributors should rebase their feature branches (pull request).

The reason they give is for clean git history on main.

The more important reason is ensure the PR branch actually works if merged into current main. If I add my change onto main, does it then build, pass all tests, etc? What if my PR branch is old, and new commits have been added onto main that I don't have in my PR branch? Then I can merge and break main. That's why you need to update your PR branch to include the newer commits from main (and the "update" could be a rebase or a merge from main or possibly something else).

The downside of requiring contributors to rebase their PR branch is (1) people are confused about rebase and (2) if your repository has many contributors and frequent merges into main, then contributors will need to frequently rebase their PR branch, and each rebase their PR checks need to re-run, which can be time consuming.

My preference with Github is to squash merge into main[1] to keep clean git history on main. And to use merge queue[2], which effectively creates a temp branch of main+PR, runs your CI checks, and then the PR merge succeeds into main only if checks pass on the temp branch. This approach keeps super clean history on main, where every commit includes a specific PR number, and more importantly minimizes friction for contributors by reducing frequent PR rebases on large/busy repos. And it ensures main is never broken (as far as your CI checks can catch issues). There's also basically no downside for very small repos either.

1. https://docs.github.com/en/repositories/configuring-branches...

2. https://docs.github.com/en/repositories/configuring-branches...

Re: Git Rebase for the Terrified

#175

Post by PaulDavisThe1st »

layer8 wrote: post #173
PaulDavisThe1st wrote: post #151

Earlier quoted context omitted.

You can make long lived feature branches work with rebase, you just have to regularly rebase along the way. I had a branch that lived for more than a year, ended up with 800+ commits on it. I rebased along the way, and the predictably the final merge was smooth and easy.

I don’t see how rebase frequency changes the problem of getting conflicts with some random commit within your long-lived branch, when doing a rebase. I rebase often myself, but I don’t understand the logic here.

1) because git rerere remembers the resolutions to the ..

2) small conflicts when rebasing the long lived branch on the main branch

if instead I delayed any rebasing until the long lived branch was done, I'd have no idea of the scale of the conflicts, and the task could be very, very different.

Granted, in some cases there would be no or very few conflicts, and then both approaches (long-lived branch with or without rebases along the way) would be similar.

Re: Git Rebase for the Terrified

#176

Post by chuckadams »

wonger_ wrote: post #119
Marsymars wrote: post #98

Earlier quoted context omitted.

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.

It seems to me the "Not Rocket Science" invariant is upheld if you just require all PRs to be fast-forward changes. Which I guess is an argument in support of rebase, but a clean merge counts too. If the test suite passes on the PR branch, it'll pass on main, because that's what main will be afterward. Ideally you don't even test the same commit hash twice.

If you have expensive e2e tests, then you might want to keep a 'latest' tag on main that's only updated when those pass.

Re: Git Rebase for the Terrified

#177

Post by astrobe_ »

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

Oh, that's why. I barely used any CVS before Git, so I was always puzzled about the "weird" opinions on this topic. I'm still puzzled by the fact that some people seem to reject entirely the idea of rewriting history - even locally before you have pushed/published it anywhere.

Sometimes people look sort of "superstitious" to me about Git. I believe this is caused by learning Git through web front-ends such as Github, GitLab, Gitea etc., that don't tell you the entire truth; desktop GUI clients also let the users only see Git through their own, more-or-less narrow "window".

TBH, sometimes Git can behave in ways you don't expect, like seeing conflicts when you thought there wouldn't be (but up to now never things like choosing the "wrong" version when doing merges, something I did fear when I started using it a ~decade ago).

However one usually finds an explanation after the fact. Something I've learned is that Git is usually right, and forcing it to do things is a good recipe to mess things up badly.

Re: Git Rebase for the Terrified

#178

Post by magicalhippo »

WolfeReader wrote: post #169
magicalhippo wrote: post #111

Earlier quoted context omitted.

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…

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...

Re: Git Rebase for the Terrified

#179

Post by zbentley »

any1 wrote: post #99
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.

Bisect is one of those things where if you're on a certain kind of project, it's really useful, and if you're not on that kind of project you never need it.

If the contributor count is high enough (or you're otherwise in a role for which "contribution" is primarily adjusting others' code), or the behaviors that get reported in bugs are specific and testable, then bisect is invaluable.

If you're in a project where buggy behavior wasn't introduced so much as grew (e.g. the behavior evolved A -> B -> C -> D -> E over time and a bug is reported due to undesirable interactions between released/valuable features in A, C, and E), then bisecting to find "when did this start" won't tell you that much useful. If you often have to write bespoke test scripts to run in bisect (e.g. because "test for presence of bug" is a process that involves restarting/orchestrating lots of services and/or debugging by interacting with a GUI), then you have to balance the time spent writing those with the time it'd take for you to figure out the causal commit by hand. If you're in a project where you're personally familiar with roughly what was released when, or where the release process/community is well-connected, it's often better to promote practices like "ask in Slack/the mailing list whether anyone has made changes to ___ recently, whoever pipes up will help you debug" rather than "everyone should be really good at bisect". Those aren't mutually exclusive, but they both do take work to install in a community and thus have an opportunity cost.

This and many other perennial discussions about Git (including TFA) have a common cause: people assume that criticisms/recommendations for how to use Git as a release coordinator/member of a disconnected team of volunteers apply to people who use Git who are members of small, tightly-coupled teams of collaborators (e.g. working on closed-source software).

Re: Git Rebase for the Terrified

#180

Post by eeperson »

echelon wrote: post #5
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

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.

I strongly disagree. Losing this discourages swarming on issues and makes bisect worse.

> 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 only use merge commits this shouldn't be any more difficult. You just need to make sure you specify that you want to use the first parent when doing reverts.

Post reply on HN