Re: [PATCH 0/4] rename "sha1-foo" files

From: Martin Ågren <martin.agren@gmail.com>
Date: Dec 30, 2020, 08:01 UTC
Message-ID: <CAN0heSq2ttahii+tUJo92L0ERcbYuS-Z51OhMsQsd-a51SWPKQ@mail.gmail.com>
In-Reply-To: <4d1f5c59-db2c-3c88-f3ca-1edcdfb2f99e@gmail.com>

On Wed, 30 Dec 2020 at 02:29, Derrick Stolee <stolee@gmail.com> wrote:

Show 12 quoted lines

>
> 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.

Show 5 quoted lines

> 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