Re: using tree as attribute source is slow, was Re: Help troubleshoot performance regression cloning with depth: git 2.44 vs git 2.42

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

 



Karthik Nayak <karthik.188@xxxxxxxxx> writes:

> Taylor Blau <me@xxxxxxxxxxxx> writes:
>
>> I could be misunderstanding the original intent of John's patch (the
>> commit message there isn't clear whether the change was intended to
>> target just check-attr or all of Git). But my hope is that it was the
>> former, which this patch preserves.
>>
>
> From the series [1] it becomes more clear that the intention was to
> target all commands.
>
> [1]: https://lore.kernel.org/git/pull.1577.v5.git.git.1697218770.gitgitgadget@xxxxxxxxx/

True.  

We could drop [1/2] from the series in the meantime to make it a
GitLab installation specific issue where they explicitly use
attr.tree to point at HEAD ;-) That is not solving anything for
those who set attr.tree (in a sense, they are buying the feature
with overhead of reading attributes from the named tree), but at
least for most people who are used to seeing the bare repository
ignoring the attributes, it would be an improvement to drop the
"bare repositories the tree of the HEAD commit is used to look up
attributes files by default" half from the series.





[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