| Message ID | cover.1609282997.git.martin.agren@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | rename "sha1-foo" files | expand |
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
On 2020-12-29 at 23:52:56, 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 agree that this series looks pretty good, and thanks for sending it. This series ended up being a lot smaller than I expected given the work on the transition, which is a nice surprise and also means it's less likely to conflict with other topics in flight.
On Wed, 30 Dec 2020 at 02:29, Derrick Stolee <stolee@gmail.com> wrote: > > 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. I built this on v2.30.0 and FWIW, it merges cleanly to seen. It could of course be that there are topics on the mailing list that Junio didn't pick up during the rc period so that there are conflicts just waiting to happen. > 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. Ok, I see. Well, if you and/or others feel we should aim for a 100% rename, I don't mind splitting the patches. My gut reaction is along your "only works if the rule is always followed", plus I wonder if there are actually Git developers using a blobless partial clone of git.git [other than for testing blobless partial clones]. Martin
On Wed, 30 Dec 2020 at 05:22, brian m. carlson <sandals@crustytoothpaste.net> wrote: > > On 2020-12-29 at 23:52:56, 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 agree that this series looks pretty good, and thanks for sending it. > This series ended up being a lot smaller than I expected given the work > on the transition, which is a nice surprise and also means it's less > likely to conflict with other topics in flight. It's a lot smaller than I expected, too -- I looked into one file and figured it would be littered with "sha" instances, but was pleasantly surprised so I continued. Certainly, the only reason this series is smaller than expected is because of all the work that has already been put into the transition. Thank you! Martin
On 12/30/2020 3:01 AM, Martin Ågren wrote: > On Wed, 30 Dec 2020 at 02:29, Derrick Stolee <stolee@gmail.com> wrote: >> 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. > > Ok, I see. Well, if you and/or others feel we should aim for a 100% > rename, I don't mind splitting the patches. My gut reaction is along > your "only works if the rule is always followed", plus I wonder if there > are actually Git developers using a blobless partial clone of git.git > [other than for testing blobless partial clones]. The upside is so small, it is not worth re-rolling your series. I was just thinking out loud to justify my first gut reaction. Even in blobless clones, this is not a huge cost (as long as we didn't also add or remove enormous blobs). This behavior of "filling in the gaps" is expected we use the repository. Thanks, -Stolee