LWN: Comments on "Cook: Colliding with the SHA prefix of Linux's initial Git commit"

Just describe it

mathstuf — Thu, 09 Jan 2025 18:24:34 +0000

Eh, I think limiting to tags present on some remote would also suffice and probably be more robust (in case you also sign tags for your internal development). The traversal bug just needs some elbow grease (assuming the perf hit is acceptable…maybe only run it if commits with equal commit times to break the tie appropriately?).

Just describe it

smurf — Thu, 09 Jan 2025 16:22:57 +0000

> I don't think I can recommend `git describe` for this purpose.

Maybe not currently, but fixing these problems (maybe only consider signed tags?) shouldn't be too difficult.

Totally something Case would do

Lennie — Fri, 03 Jan 2025 22:16:25 +0000

I guess we could say: Kees in point. :-)

I wish for a longer prefix

mfranc — Fri, 03 Jan 2025 12:47:02 +0000

Unlikely with libgit2. The biggest problem of git itself is that you cannot use it as a library.

I wish for a longer prefix

jirislaby — Fri, 03 Jan 2025 07:50:23 +0000

Perhaps git should have been taught to do the inversion of oneline/abbrev first? So that we all have the decoding on one central place. It has to be written (or taken from git web parsers) now anyway.

I wish for a longer prefix

mfranc — Thu, 02 Jan 2025 15:48:54 +0000

As somebody who wrote 2 tools for parsing kernel git commits (with libgit2) and is in the process writing the third, I find the ideas around comparing Subject or any other additional metadata along the hash prefix terrible. It is so much easier to simply call rev-parse on a hash prefix (no matter how long) than any proposed alternative.

Totally something Case would do

deptrai — Wed, 01 Jan 2025 20:39:12 +0000

Probably Simon Weckert.

https://www.simonweckert.com/googlemapshacks.html
https://www.wired.com/story/99-phones-fake-google-maps-tr...

SHAs in commit messages

ceplm — Wed, 01 Jan 2025 18:26:58 +0000

Yes, and Git (not GitHub) supports sha256-based repositories (e.g., https://src.opensuse.org/mcepl/dictd … it is being used so far in development by openSUSE for packaging repos; and yes, of course, Gitea supports it as well).

Totally something Case would do

ssmith32 — Wed, 01 Jan 2025 00:29:49 +0000

Oof, I started reading that and thought it was going to be a sly allusion to Neuromancer ... it isn't actually a bad start to a short bit of fan fic, imho 😄

SHAs in commit messages

epa — Wed, 01 Jan 2025 00:24:54 +0000

Not git log, but many other git commands show an abbreviated SHA by default.

SHAs in commit messages

NYKevin — Tue, 31 Dec 2024 17:03:15 +0000

People are not going to copy the full ID unless you print the full ID for them to copy. So if you want people to copy the full ID, you have to display the full ID for them to copy, and it has to be the default behavior of git log etc. (because people are lazy and will grab the abbreviation if it is more convenient).

But that's obviously a bad user experience. The better option would be one or more of the following:

* As suggested, auto-expand unambiguous abbreviations to full hashes at commit time (with a flag to disable this behavior, and possibly also a warning message on stderr to let you know that an expansion has occurred). Auto-abbreviate them in git log (with a flag to disable).
* Provide a reasonably terse syntax that performs auto-expansion at commit time (and can be escaped or disabled if necessary). You can probably do this now by configuring your editor to perform the expansion, but it would also require everyone to agree that expansion is preferred.
* When resolving commit IDs that appear in a given commit message, first look for matching ancestors of the given commit, then for matching non-descendant commits that are older than the given commit according to the date field, then for matching non-descendant commits that are less than 24 hours younger (to allow for wrong timezone shenanigans), and finally for all matching non-descendant commits in the repo. This requires you to know where the commit ID came from in the first place, but forges do in fact have that information when they are linkifying a commit message. Of course, they might already be doing something like this.

Just describe it

mathstuf — Tue, 31 Dec 2024 16:21:48 +0000

This assumes that annotated tags have some source of "truth" to them and are never used outside of that within a repository. There are also multiple names for a commit based on which tags are available locally. There's also this bug[1] that still exists which can get the wrong tag if you have automated merges in the history that share a (1-second resolution) timestamp.

I don't think I can recommend `git describe` for this purpose.

[1] https://lore.kernel.org/git/ZNffWAgldUZdpQcr@farprobe/T/#u

SHAs in commit messages

jorgegv — Tue, 31 Dec 2024 15:33:17 +0000

You could shorten in 'git log' but that doesn't do much to encourage use of the full SHA in the original message. If only eight characters are going to be printed, why bother pasting in all of it?

Because when you are pasting a commit ID, you have most probably copied it from the terminal (or somewhere else), and doing double click on the full commit ID selects it completely? I mean: I believe nobody keys in commit IDs letter by letter, but instead copy&paste them everywhere (or use some kind of autocomplete), and the copy operation is the same to copy the full ID or an abbreviation.

My view is that commit IDs should be used in full size whenever a machine could be using them, and only shorten them when showing then to a human. As someone already said, that's what forges already do, and I think it's the correct way.

Just describe it

jengelh — Tue, 31 Dec 2024 15:26:28 +0000

Two readily available options (other than the obvious way of using the full hash):

1. `git describe`: "v6.11-7343-g70fd1966c93b". The chance that there are two commits with prefix 70fd19 *and* with distance 7343 from v6.11 is a lot lower than the chance that there are two commits with prefix 70fd19 anywhere in the entire history.

2. `git describe --contains` (if it yields a result): "v6.12~355^2~3" is unambiguous, at least as long as the tree has no grafts (or the modern equivalent thereof).

SHAs in commit messages

adobriyan — Tue, 31 Dec 2024 14:21:01 +0000

<sha1></sha1> won't be that bad but it is too late. "sha1:..." is probably the way to go.

Totally something Case would do

Wol — Tue, 31 Dec 2024 13:38:03 +0000

I remember Google Maps messing up badly, but that was just Maps being stupid.

Embankment was closed just west of Charing Cross. Seeing that there was not much traffic on a major thoroughfare, Google Maps was trying to send all the traffic down Embankment ...

I was wondering whether to trust Google Maps or not, and wish I hadn't - once committed, it took me well over half an hour to extricate myself just to get back to where I was, quite possibly an hour ... like *MOST* AI, when you need it most is exactly when it is most likely to screw up. If there's a traffic jam, trust the official diversion or your instincts, as AI is quite likely to mess up completely. I think I completely lost faith in it when it tried to divert a closed motorway down a single-track road ...

Cheers,
Wol

Totally something Case would do

bof — Tue, 31 Dec 2024 12:15:52 +0000

That reminds me of a funny guy I met on a vacation in Berlin. It was on a calm little street, and he was trodding along the sidewalk with a handcart full of switched on mobile phones. Asked him what he's doing. He happily explained that he's teaching Google Maps that the street is congested so often that it would be totally silly to send traffic through.

I laughed so hard...

SHAs in commit messages

epa — Tue, 31 Dec 2024 11:32:42 +0000

You could shorten in 'git log' but that doesn't do much to encourage use of the full SHA in the original message. If only eight characters are going to be printed, why bother pasting in all of it? What's missing is the input side: when a commit message contains something that looks like an SHA, abbreviated or not, look it up in the current repository and store the full hex string. Better to do this guessing and magic at the point when the message is written, rather than later when it's displayed, by which time the shortened string may have become ambiguous. And then rebasing and cherry-picking can repoint to a new commit, prompting the user if needed.

SHAs in commit messages

pbonzini — Tue, 31 Dec 2024 10:33:23 +0000

You could just have automatic shortening of SHA1 commit IDs in "git log", though that probably would require wrapping as well. It's essentially what the various git forges do when you paste a full commit ID in a comment or a commit message.

Totally something Case would do

lkundrak — Tue, 31 Dec 2024 10:15:21 +0000

and possible new nickname

SHAs in commit messages

epa — Tue, 31 Dec 2024 10:08:28 +0000

It’s always seemed a bit of a gap in git’s functionality that there is no official way to mark an SHA in a commit message. If a web interface wants to hyperlink it, for example, it has to sniff for a likely-looking sequence of 0-9a-f characters. Whereas if the SHA were marked it could be automatically linked and abbreviated too for human readers. When rebasing, messages like “this reverts commit abc” or “see also bcd” could automatically be updated to the new commit in the rebased series.

(I know worse is better and you can build anything you want on top of an unstructured field, but there is value in having a single defined way which you can reasonably expect most people to follow.)

Totally something Case would do

Cyberax — Tue, 31 Dec 2024 00:50:25 +0000

Another case of namespace collision.

Totally something Case would do

mricon — Mon, 30 Dec 2024 23:08:05 +0000

Lol, this is what happens when I try to dictate and don't check that Kees got turned into Case. Sorry, Kees!

Totally something Case would do

mricon — Mon, 30 Dec 2024 22:39:29 +0000

When I first met Case, it was at a conference in San Diego, when he was plugging in a WiFi router he brought with him from home into an outlet in the hallway. His stated reason was to hope that the SSID is added to the Apple/Google tracking databases, so next time someone drives by his house in Portland and registers his home wifi signal, the tracker would be confused.

Anyway, all of this is to say that this story 100% checks out and this is totally something Case would do.