Automated tools should fail on ambiguity
Automated tools should fail on ambiguity
Posted Dec 16, 2024 11:59 UTC (Mon) by farnz (subscriber, #17727)In reply to: Automated tools should fail on ambiguity by intelfx
Parent article: Facing the Git commit-ID collision catastrophe
Git's porcelain is not the only tool out there that uses or generates truncated hashes; CI systems consume them, and forges generate them in their Web UIs. Hopefully, they all get things right, but the nature of code is that some of these systems will have bugs.
Posted Dec 17, 2024 18:24 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Posted Dec 17, 2024 18:28 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (2 responses)
I would hope that all of these cases are at least considered by forges and CIs, but once you have a human in the loop, they will find ways to do weird things that you did not expect, and did not allow for - and the best a forge or CI can do is fail when I ask it to interact with an ambiguous commit hash.
Posted Dec 18, 2024 14:31 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Yes, humans always make things messy ;) . AFAIK, all APIs would stop something ambiguous at the API surface rather than after figuring out what work needs to be done. And, AFAIK, most APIs want names of refs or forge entities (like PRs) rather than commit IDs. Not that the latter don't exist, but I don't usually find interest in CI results of a specific commit rather than a ref or current PR state (without naming it by one of those ways).
Posted Dec 18, 2024 14:40 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Note that a commit ID in git qualifies as a refspec, and that's what most APIs actually ask for - something that git can resolve to a commit. And the trouble kicks in when you accept a refspec - because main, refs/branches/main, aef25be35d23 and aef25be35d23ec768eed08bfcf7ca3cf9685bc28 are all valid refspecs in git, but the truncated hash can be ambiguous with other commits, and only the full hash is unambiguous over time (since the others are mutable).
And IME, if you don't run CI on every single commit, people do ask for CI for a specific commit by hash, rather than mutable ref - when something worked 10 commits ago, but fails now, asking CI to fill in the gaps is useful.
Automated tools should fail on ambiguity
You do, however, have to cope with users doing things like highlighting the truncated hash and copying it (rather than using the affordances in the UI to get a full hash), taking a screenshot and attaching that to a mail (where the recipient then has to reconstruct the hash from the picture), and pasting a truncated hash into the CI's "request a build of an arbitrary commit" field.
Automated tools should fail on ambiguity
Automated tools should fail on ambiguity
Automated tools should fail on ambiguity