On Sun, Aug 25, 2013 at 10:07 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Duy Nguyen <pclo...@gmail.com> writes:
>> On Mon, Aug 19, 2013 at 2:41 AM, Thomas Gummerer <t.gumme...@gmail.com> 
>> wrote:
>> I'm done reviewing this version (I neglected the extension writing
>> patches because after spending hours on the main write patch I don't
>> want to look at them anymore :p). Now that rc period is over, with a
>> partial write proof-of-concept, I think it's enough to call Junio's
>> attention on the series, see if we have any chance of merging it. The
>> partial write POC is needed to make sure we don't overlook anything,
>> just support update-index is enough.
> I've been following the review comment threads after looking at the
> patches myself when they were posted. I was hoping to see some API
> improvement over the current "we (have to) have everything available
> in-core in a flat array" model, which gives a lot of convenience and
> IO overhead at the same time, that would make me say "yes, this
> operation, that we need to do very often, will certainly be helped
> by this new API, and in order to support that style of API better,
> the current file format is inadequate and we do need to go to the
> proposed tree like on-disk format" for at least one, but
> unfortunately I haven't found any (yet).

Thomas is in the best position to answer this, but I'll give it a try.
In my opinon, v2-4 works well for moderate-sized worktrees, v5 aims to
make the index scale better. One way to make it scale is not to read
the whole index up when you only need a portion of the index.
read_index_filtered() enables this. We could implement
read_index_filtered() on v2 too, but because v2 lacks proper data
structure to support it, we need to scan through all on-disk entries.
"git diff" and "git status" with pathspec may benefit from this (and
for large worktrees, people better use pathspec than whole-tree
"status"). The flat (but not full) array model seems best fit because
we still need to support v2. Another v5 improvement is fast "git add
-u/git commit -a" when partial write is implemented. I don't think
such a patch is posted. There may be API addition to aid v5 code but
it should not be big API change.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to