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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 30 Dec 2020 at 02:29, Derrick Stolee <stolee@xxxxxxxxx> 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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux