On 12/29/2020 6:52 PM, Martin Ågren wrote: > 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
