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

Git rebase, what can go wrong

jvns.ca

Post reply on HN
Print view View original

391–400 of 404 posts

Re: Git rebase, what can go wrong

#391

Post by mixmastamyk »

seba_dos1 wrote: post #385
Chris_Newton wrote: post #367

Earlier quoted context omitted.

But, in all of those cases, things are done because they beneficial impact in final code and speed of delivery. Beautiful git history does not have such tangible measurable benefit. I respectfully disagree. In my experience, a tidy history directly benefits both efficiency and outcomes of code reviews, speeds up investigations of both bug reports and sometimes general background before starting new development, makes…

Fully agreed. Seems to me that most people who don't care about curating their commits (and either leave a mess or squash everything at merge regardless of context) simply don't work on projects that are either complex, distributed or long-living enough, so they can easily afford such carelessness.

Nope, ~15 year project here. No one is reading obsolete commit messages when there are hundreds of files to get familiar with today.

Not to mention quality is significantly higher now so you wouldn't want to refer to a granular history of crap anyway. Any time spent on that would have been completely wasted as I wipe out a thousand line file for a new one with a hundred lines because requests hadn't been invented yet and the original implementer didn't understand network protocols or how to use argparse and implemented it from scratch poorly.

Re: Git rebase, what can go wrong

#392

Post by gitaarik »

phendrenad2 wrote: post #156

I'm jealous of people who enjoy rebasing. Such a simple life they must lead. When I'm tasked with rebasing a feature branch with 1,000 commits, written by 10 different people, onto a new release branch with another 1,000 new unrelated commits, written by 10 different people, I really start to question my life choices.

The linked article actually has a section "rebasing a lot of commits is hard" and it's conclusion is to rather not do it, mostly regarding what is mentioned above that section. But if you know how to use rerere properly, like some of the commenters here have pointed out, it could very well make your life a lot easier if you really want to rebase so many commits. And btw, make sure nobody is working on any of these branches or forks of those branches anymore, because after the rebase they won't be able to merge anymore.

Re: Git rebase, what can go wrong

#393

Post by rhinoceraptor »

naasking wrote: post #319
rhinoceraptor wrote: post #289

Earlier quoted context omitted.

There is obviously a point where you do not want full history. For example, it would absurd to use your editor's undo history tree with keystroke level granularity as your VCS, because in most of those points in history, the code won't even compile because you were in the middle of typing a word. If your goal is to be able to revert the codebase to a previous version, then you want your history to a series of well pr…

Clearly that's the reason you make a commit to begin with. Erasing that commit history is just silly.

I make a commit whenever I want to save my progress, and rarely is it ever in a state that could even be called a "version" of the software that one would want to revert to, until my feature branch is complete and ready for code review.

At that point I have a much better idea of the scope of my changes, and I can revise them into a few coherent commits, rather than a mess of "WIP" commits that are not a useful history to keep.

Re: Git rebase, what can go wrong

#394

Post by phendrenad2 »

gitaarik wrote: post #392
phendrenad2 wrote: post #156

I'm jealous of people who enjoy rebasing. Such a simple life they must lead. When I'm tasked with rebasing a feature branch with 1,000 commits, written by 10 different people, onto a new release branch with another 1,000 new unrelated commits, written by 10 different people, I really start to question my life choices.

The linked article actually has a section "rebasing a lot of commits is hard" and it's conclusion is to rather not do it, mostly regarding what is mentioned above that section. But if you know how to use rerere properly, like some of the commenters here have pointed out, it could very well make your life a lot easier if you really want to rebase so many commits. And btw, make sure nobody is working on any of these br…

Unfortunately rerere only solves the tedium of this task. I'm much more annoyed by cases like this: Person1 modifies line of code A (commit 1). In the other branch, Person2 modifies that line (commit 2). Then, Person2 notices that the first person has made a change, and takes that into account by rewriting their own change (commit 3). When you try to rebase these two branches, you might have to resolve a conflict between Commits 1 and 2, which is pointless work because those were never intended to coexist.

Re: Git rebase, what can go wrong

#395

Post by seba_dos1 »

mixmastamyk wrote: post #391
seba_dos1 wrote: post #385

Earlier quoted context omitted.

Fully agreed. Seems to me that most people who don't care about curating their commits (and either leave a mess or squash everything at merge regardless of context) simply don't work on projects that are either complex, distributed or long-living enough, so they can easily afford such carelessness.

Nope, ~15 year project here. No one is reading obsolete commit messages when there are hundreds of files to get familiar with today. Not to mention quality is significantly higher now so you wouldn't want to refer to a granular history of crap anyway. Any time spent on that would have been completely wasted as I wipe out a thousand line file for a new one with a hundred lines because requests hadn't been invented yet…

Yeah, as I suspected.

If you can afford your first instinct to be reimplementing things from scratch, your understanding of the value provided by proper version control will be limited. Some of us work with constantly changing code developed by thousands of people from all around the world in projects that 15 years ago were migrating to git and that have tons of downstreams, and are thankful for maintainers and processes that keep their commit graphs useful.

Though that said, once you're comfortable enough with git you'll be thanking yourself for commit hygiene even when coming back to your few years old single-person codebases.

In my experience, developer's work consists mostly of gaining understanding of codebases. It's like being a detective. Writing new code happens too, but not as often and it's not as impactful (and usually can and should be handled by less experienced devs wherever possible). Among the most impactful things are single line changes that took a week to write, or a few dozen lines that took months. Rewriting existing code from scratch is something that happens only as a last resort and after very careful consideration. Maintaining some basic version control hygiene makes a whole world of difference in such work. Sure, you can live without it, but you can also live without docs, comments or tests (and sometimes have to - which makes you appreciate them when they're there).

Re: Git rebase, what can go wrong

#396

Post by seba_dos1 »

PhilippGille wrote: post #389
sam_bristow wrote: post #343

Earlier quoted context omitted.

Unfortunately I haven't seen a git forge that will let you do "autosquash on merge" so I could just push up fixup commits as part of an merge request.

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

That always squashes the whole PR into a single commit, making it not very useful in practice. Git's autosquashing is much more powerful than that.

Re: Git rebase, what can go wrong

#397

Post by seba_dos1 »

thebigspacefuck wrote: post #329
ohwellhere wrote: post #26

Earlier quoted context omitted.

The way I phrase and teach what I consider to be the important rule of git is: > Don't rewrite history on shared branches with proper communication. I don't teach "never", I don't teach that `main` is special, I don't teach that force pushing is forbidden, because I don't believe in those things. I highly prefer a rebase-heavy workflow. In addition to not "cluttering" the history, it's an invaluable tool to keep comm…

It’s annoying when someone force pushes to a branch that you just reviewed, but you can no longer see the history so you have to scan through the whole PR you already reviewed looking for the change. Please just commit the fix, let me see it, then squash it.

You can just diff the previous head with the new one. In GitLab, it's simply a matter of clicking "Compare with previous version". Locally, it's `git diff branch@{1}..branch`.

It's only becoming tricky if the MR has been rebased onto a different base in the process, but it's not very hard to deal with that too if needed (just annoying).

Re: Git rebase, what can go wrong

#399

Post by seba_dos1 »

seba_dos1 wrote: post #397
thebigspacefuck wrote: post #329

Earlier quoted context omitted.

It’s annoying when someone force pushes to a branch that you just reviewed, but you can no longer see the history so you have to scan through the whole PR you already reviewed looking for the change. Please just commit the fix, let me see it, then squash it.

You can just diff the previous head with the new one. In GitLab, it's simply a matter of clicking "Compare with previous version". Locally, it's `git diff branch@{1}..branch`. It's only becoming tricky if the MR has been rebased onto a different base in the process, but it's not very hard to deal with that too if needed (just annoying).

Actually, it's not that annoying at all - TIL about `git range-diff`.

Re: Git rebase, what can go wrong

#400

Post by gitaarik »

phendrenad2 wrote: post #394
gitaarik wrote: post #392

Earlier quoted context omitted.

The linked article actually has a section "rebasing a lot of commits is hard" and it's conclusion is to rather not do it, mostly regarding what is mentioned above that section. But if you know how to use rerere properly, like some of the commenters here have pointed out, it could very well make your life a lot easier if you really want to rebase so many commits. And btw, make sure nobody is working on any of these br…

Unfortunately rerere only solves the tedium of this task. I'm much more annoyed by cases like this: Person1 modifies line of code A (commit 1). In the other branch, Person2 modifies that line (commit 2). Then, Person2 notices that the first person has made a change, and takes that into account by rewriting their own change (commit 3). When you try to rebase these two branches, you might have to resolve a conflict bet…

Doesn't what this comment says solve this for you? https://news.ycombinator.com/item?id=38166928
Post reply on HN