SHAs in commit messages

Posted Dec 31, 2024 15:33 UTC (Tue) by jorgegv (subscriber, #60484)
In reply to: SHAs in commit messages by epa
Parent article: Cook: Colliding with the SHA prefix of Linux's initial Git commit

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.

SHAs in commit messages

Posted Dec 31, 2024 17:03 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

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.

SHAs in commit messages

Posted Jan 1, 2025 0:24 UTC (Wed) by epa (subscriber, #39769) [Link]

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