Re: [PATCH 0/4] rename "sha1-foo" files
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Dec 30, 2020, 01:29 UTC
- Message-ID
- <4d1f5c59-db2c-3c88-f3ca-1edcdfb2f99e@gmail.com>
- In-Reply-To
- <cover.1609282997.git.martin.agren@gmail.com>
On 12/29/2020 6:52 PM, Martin Ågren wrote:
Show 5 quoted lines
> We have some source files with filenames such as sha1-lookup.c and > sha1-name.c containing a few variable names, comments and the like > referencing "sha1". But they are able to handle SHA-256 as well. Here's > my attempt at removing "sha1" from the contents and names of these > files.
I think this is a good effort. Timing is good after the v2.30.0 release. As long as this doesn't conflict drastically with things in flight, I think this change should "jump the line" and merge with priority to avoid future conflicts.
It _has_ been bothering me that it was still sha1-file.c.
Oh, and I remembered the one semi-legitimate case to try for exact renames whenever possible: "git log --follow" will download fewer blobs in a blobless partial clone (--filter=blob:none). Of course, this only works if the rule is always followed and is not really a justification for doubling the number of your patches.
It does make me think that it is worth checking if "git log --follow" short-circuits the full rename detection if the path it cares about was found to be an exact rename (so doing a full content-rename check on the other adds and deletes is worthless). Making a note [1] to investigate.
[1] https://github.com/gitgitgadget/git/issues/827
Thanks, -Stolee