Linux 5.12's very bad, double ungood day

Posted Mar 8, 2021 19:28 UTC (Mon) by luto (guest, #39314)
Parent article: Linux 5.12's very bad, double ungood day

I would consider this situation to demonstrate a problem with git. Sure, maintainers should avoid publishing known-bad trees / commits, but git bisect should be able to avoid generating known-bad states for testing.

Linux 5.12's very bad, double ungood day

Posted Mar 8, 2021 20:13 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

I'd have a way to add a commit range to something like a `bisect.avoidIfPossible` configuration. It would just treat any commit in there as `skip` by default and would delve in only on explicit requirements (maybe each range could even have an explanation for the exclusion so I can know whether it applies to my situation). However…

Git just generally has a problem with shipping configuration values around. I can't make bullet-proof commands for others to use because I don't even know what remote names are in use. I vastly prefer `origin` for the main repo and `$prefix/$username` for any forks (including mine and the prefix depends on the hosting service). Others prefer `origin` for their fork and `upstream` for the main repository. Useful aliases, hooks, etc. all have non-existent ways of being distributed in git today. We have a script that developers should run to at least match the docs, but that's not generally used.

Linux 5.12's very bad, double ungood day

Posted Mar 8, 2021 20:28 UTC (Mon) by pebolle (guest, #35204) [Link] (5 responses)

What I wonder is why v5.12-rc2 wasn't done like this:
- restart at v5.11;
- add everything in v5.12-rc1-dontuse except the misguided commit;
- add the misguided commit and it's fix squashed as a single commit;
- add everything else that is now in v5.12-rc2 but not in v5.12-rc1-dontuse.

That should make v5.12-rc1-dontuse a dead end which no-one would ever hit while bisecting. (And v5.12-rc2 basically a second try at a v5.12-rc1.) Or doesn't git work like that?

Linux 5.12's very bad, double ungood day

Posted Mar 8, 2021 21:13 UTC (Mon) by josh (subscriber, #17465) [Link]

That could absolutely be done. It'd mean that the repository would have a non-fast-forwarding change, which would be disruptive. It'd also set a precedent that non-fast-forwarding changes are an option for a serious enough bug, which might be undesirable.

Linux 5.12's very bad, double ungood day

Posted Mar 8, 2021 21:16 UTC (Mon) by geert (subscriber, #98403) [Link] (3 responses)

Following your approach would rebase the master branch of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/..., which is something Linus does not want to do ever. This would affect any tree that has pulled from this branch after the bad commit was merged into his tree.

Linux 5.12's very bad, double ungood day

Posted Mar 9, 2021 8:46 UTC (Tue) by marcH (subscriber, #57642) [Link]

> This would affect any tree that has pulled from this branch after the bad commit was merged into his tree.

That's the goal.

Linux 5.12's very bad, double ungood day

Posted Mar 9, 2021 10:21 UTC (Tue) by pr1268 (guest, #24648) [Link] (1 responses)

Following your approach would rebase the master branch [...], which is something Linus does not want to do ever.

But, in this particular case, he's making an exception. From our editor's article (emphasis mine):

That sort of rebasing would normally be frowned upon, but Torvalds made it clear that it is permissible — and expected — this time.

Linux 5.12's very bad, double ungood day

Posted Mar 9, 2021 10:44 UTC (Tue) by geert (subscriber, #98403) [Link]

The discussion was about rebasing Linus Torvalds' master branch, not about rebasing maintainers' branches for submitting pull requests.
If Linus had been comfortable about rebasing his own master branch, he would have done so for sure.