Re: [PATCH 1/6] read-cache: use sha1file for sha1 calculation

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

Having no explanation on any of the patch in the series without cover letter makes it hard to comment on anything, and not having any numbers makes it even harder after guessing that this is about some performance tweaks for 2M entry index cases.

This is open source, and I wouldn't stop you from spending time on anything that interests you.

But having said that, if you have extra Git time, I would still rather see you spend it first on tying up loose ends of your topics in flight and on helping others that touch parts that are related to areas that you have already thought about, namely:

 (1) nd/commit-ignore-i-t-a, which I think should be marketted as fixing
     an earlier UI mistake and presented with a clean migration path to
     make the updated behaviour the default in the future; and

 (2) the negative pathspec thing that resurfaced in disguise as Albert
     Yale's "grep --exclude" series.

than playing with the approach of this series. The two reasons I suspect that spending your time on this series will give us much less value than the above two topics out of you are:

 (1) While I think 2M-entry index is an interesting issue, it does not
     affect most of the people; and more importantly

 (2) I think the proper way to handle 2M-entry index case is to avoid
     having to write and read the whole 2M-entry as a flat table in the
     first place, not by weakening how its integrity is assured in order
     to micro-tweak the read/write efficiency without re-examining the
     flatness of the current in-core index [*1*].

The first patch that reuses the existing csum-file API to older code that was written before csum-file was invented is probably a good thing to do, though, independent of the 2M-entry issue.

Thanks.

[Footnote]

*1* A possible approach might be to stuff unmodified trees in the index without exploding them into its components, and as entries are modified, lazily expand these "tree" entries, while ensuring the "unmodified" parts remain unmodified by turning the files in the working tree read-only and requiring the user to say "git edit" or "git open" or something before starting to edit. But as I said, I consider this not an ultra-urgent issue, so I haven't thought things through yet.