3 ms·

> I don't really understand why this would be important. It is important because not everyone does this: > [...] and then put commits around it as needed to e

> I don't really understand why this would be important. It is important because not everyone does this: > [...] and then put commits around it as needed to ensure that it can be merged with by fast-forward to preserve it. Good quality rebases like those are more likely to happen on patch-based workflows (not necessarily email), compared to PR-based workflows, because there's more focus on the individual commits themselves being meaningful, with straight line history being mostly a nice side-effect. With "more likely" I mean literally that, more likely; I'm not saying it only happens there. In PR-based workflows on the other hand, people tend to care only about HEAD. PR color is green? LGTM ship it :rocketemoji:. Most just read blog post by git shaman saying straight line pretty and then go to GitHub and enable the setting for that without thinking more than that; or learn that you can reorder commits to tell pretty story and do it without thinking more than that. Though it's also true that some repository owners only care about the tagged commits; all untagged commits could be broken and they don't care because "it's supposed to be in progress" and "as long as the most recent commit works, it's fine". They've never needed to checkout any specific commit on any repository (understandable if they never contribute to others' repositories). --- Also, you probably noticed already because of your edit, but re: > If I'm not the one committing, why should I care about what intermediate states that the person who committed them don't even care about enough to preserve? With "intermediate states" I don't mean what other people committed; I mean all your own commits that you just rebased (all your own commits whose hash changed) that are not the most recent one. You are in the minority that fixes those; most people I've met would be like: * All commits are tested and work fine. * Create PR. * See CI fails because branch is outdated. * Rebase PR onto most recent commit of main branch. * See CI fails because, idk, let's say it's something easy to fix like a more strict linter config. * Make a new commit that fixes the linter errors. * CI passes. * Everyone LGTM's the PR and it gets fast-forwarded. * The PR had `n` commits, but now `n-1` of those fail the linter because they contain the new config for the linter, but the committer never bothered to look at those commits, they only cared about HEAD. Those `n-1` commits "contain trees that the committer never saw at any point at all" (copy-pasting that quote from my message). And it doesn't matter that those commits are broken because for those people having pretty straight line is way more important than a working commit. The recent FreeBSD/Netflix thingy[1] had a successful bisect only because when people rebase stuff in there, they don't YOLO those `n-1` rebased commits. If that had been any of my previous workplaces, or anyone who only rebase because "straight line pretty" without thinking anything more than that, then that whole bisect could have gone way worse. [1]: https://news.ycombinator.com/item?id=40630699 https://news.ycombinator.com/item?id=40630699

saghm 2y ago
All of your points seem accurate to me, but I don't see how merge workflows fix any of it. It seems like the same thing could happen where each commit along the way is broken until the final one, and then it's merged as-is. I don't think that having those intermediate commits being the exact ones that the person made is a solution because the problem you're describing is social, not technical; people not caring about committing messy intermediate state to the repo isn't going to be fixed by using merging rather than rebasing. The only workflow that would eliminate the problem entirely is to completely remove all intermediate state by squashing to a single commit before any merge, at which point doing a merge versus a rebase won't matter.
- quectophoton 2y ago
  Neither workflow fixes anything. Each strategy helps with some things, but require discipline in other things. Using merges lets you commit as you go, without needing to go back to repeat a test on a previous commit, and only worry about conflicts at the end of your development. Write code, test, commit. Write more code, test, commit. Cherry-pick, test, commit. Merge into main, fix conflicts, finish merge. There's never a need to go back and re-test, like with rebase, because the commits that were already tested are still there. But they require discipline to not pollute history, and being open to squashing commits that don't add any useful information (you want to avoid having "WIP"-style commits). Using rebases lets you rewrite commits to take advantage of the most recent changes from the main branch, instead of waiting until you finish with your feature. But they require discipline to go back and repeat tests to ensure that any commit that changed still works as expected (and it's needed because the commits changed, hence their different hash, so they are no longer the commit hashes that were tested), and being open to having some merge commits (you want to avoid rebasing a 10 commit migration of your telemetry library because if 3 months later you find out your costs in production were way higher than what they told you they would be, reverting a single merge commit is more dumbproof compared to reverting a manually provided range of commits). So yes, choosing one or the other is a social problem. Both are good solutions with good discipline, and both are bad solutions with bad discipline. One of those makes it less likely for people in my bubble to make a mess out of that repo. It might be the same as for your bubble, or it might be different. But on a good project it doesn't really matter which one is done.

saghm 2y ago

All of your points seem accurate to me, but I don't see how merge workflows fix any of it. It seems like the same thing could happen where each commit along the way is broken until the final one, and then it's merged as-is. I don't think that having those intermediate commits being the exact ones that the person made is a solution because the problem you're describing is social, not technical; people not caring about committing messy intermediate state to the repo isn't going to be fixed by using merging rather than rebasing. The only workflow that would eliminate the problem entirely is to completely remove all intermediate state by squashing to a single commit before any merge, at which point doing a merge versus a rebase won't matter.

quectophoton 2y ago
Neither workflow fixes anything. Each strategy helps with some things, but require discipline in other things. Using merges lets you commit as you go, without needing to go back to repeat a test on a previous commit, and only worry about conflicts at the end of your development. Write code, test, commit. Write more code, test, commit. Cherry-pick, test, commit. Merge into main, fix conflicts, finish merge. There's never a need to go back and re-test, like with rebase, because the commits that were already tested are still there. But they require discipline to not pollute history, and being open to squashing commits that don't add any useful information (you want to avoid having "WIP"-style commits). Using rebases lets you rewrite commits to take advantage of the most recent changes from the main branch, instead of waiting until you finish with your feature. But they require discipline to go back and repeat tests to ensure that any commit that changed still works as expected (and it's needed because the commits changed, hence their different hash, so they are no longer the commit hashes that were tested), and being open to having some merge commits (you want to avoid rebasing a 10 commit migration of your telemetry library because if 3 months later you find out your costs in production were way higher than what they told you they would be, reverting a single merge commit is more dumbproof compared to reverting a manually provided range of commits). So yes, choosing one or the other is a social problem. Both are good solutions with good discipline, and both are bad solutions with bad discipline. One of those makes it less likely for people in my bubble to make a mess out of that repo. It might be the same as for your bubble, or it might be different. But on a good project it doesn't really matter which one is done.