[epolanski]

Issues should be catched by spending time in automating tests that ensure the correct functional and non functional requirements are met not by surgically maintaining a graph of codebase snapshots.

History is preserved in the branch along the PRs if needed, and it rarely is.

I'm not saying that rebasing is useless (I default to it), I'm debating if the effort is worth it in engineering terms, which I generally don't see because the benefits seem to be small compared to the cost.

[hughesjj]

This argument seems weird to me because even without rerere I found myself doing a lot more work managing merge conflicts with git merge instead of git rebase

As a git merge fan, are there any tips or tricks you suggest beyond the stock git experience when doing git merge to minimize the amount of merge conflicts you get?

I found it was especially bad when doing a git merge on a refactor, but I admit it could just be that I abandoned git merge earlier in my career before switching to rebase and never properly learned it

My most common use cases are feature or bug branches with a lifespan between less than one day and up to one month (although I absolutely have some features on pause for even over a year, in which case interactive git rebase and partially squashing WIP commits is my current method of updating)

All this is for repos from literally just me, to a few changes a month between 3 devs, to 5-2 devs doing multiple commits per day, to some open source projects with commits landing every few minutes from multiple devs if it's like a release day

My current biggest issue with rebase is verified commits with GitHub and a bit of guilt for rewriting committed feedback from other authors on my PRs

The only time I really use git merge is when I want to see how my work interplays with more than one feature branch at once, or if the feature branch I want to integrate hasn't rebases themselves in a bit and conflicts occur

[hinkley]

Most of the time I've encountered two engineers pointing fingers about who is responsible for a bug, it turns out that someone's bad merge transferred the git annotation from one engineer to another.

The first time this happened (that I caught) I had two engineers who were sniping at each other. One was older "Max" and not great at data structure algorithms. The other "Stan" was a decent coder but had a bad attitude and was awful with git. Somehow he thought he could raise his status by getting Max kicked off the team.

I come back from lunch one day and Stan is bitching about a bug in Max's new code that's causing issues. To keep these two from fighting I've been reviewing all of Max's PRs and the line of code Stan is complaining about I know for a fact I checked, and was relieved to see Max got it right the first time. But sure enough, the repo says Max fucked it up.

Twenty minutes of git archaeology later and sure enough, Stan messed up a merge and resolved the conflict wrong, introducing the phantom bug. So I showed him the step by step of my diagnosis and then we had another little talk about using rebase.

[hughesjj]

That sounds like Stan was rebasing someone else's work though?

And wait was Stan rebasing main?

I mean yeah, in that case it's definitely, definitely wrong to use rebase. In general though I always rebase my feature branch and only then merge it into main. Because it's rebased onto the head of main and thus a linear series of commits, there's no merge conflicts to fix.

[seanwilson]

> I'm not saying that rebasing is useless (I default to it), I'm debating if the effort is worth it in engineering terms, which I generally don't see because the benefits seem to be small compared to the cost.

For what's it worth, I agree for most projects I've been on. I've rarely e.g. used deep Git history forensics to figure out a regression, or to figure out why some code is the way it is. Usually I'm just tracking down the fairly recent squashed commit of a pull request that introduced the problem and it's obvious enough where to look to fix it.

I like the idea of clean, super fine-grained commits with good summaries but I never see people mention that this takes extra time to do, because putting a pull request together is usually a messy iterative process, and not a predictable sequence of clean independent commits.

Real work is more like "Add sketch of code ... Iterate some more ... Fix bug ... Iterate some more ... Upgrade library ... Really fix the bug ... Clean up ... Merge from main and get working ... Refactor ... Add comments ... Fix PR requests". Rebasing as you go or going back at the end to break that into chunks that will each independently make sense and pass tests costs a lot of time? Maybe I'm missing something?

The time vs benefit trade-off is probably different with huge teams and huge projects, but for solo projects, small teams, and medium projects the trade-offs are different.

Feels similar to test suite discussions. People don't mention there's a cost vs benefit trade-off to how fine grained your tests should be for different scenarios as it depends on a lot of factors you need to balance.

[not_kurt_godel]

The graph of snapshots is for forensics when someone breaks the tests and keeps obliviously trucking along