Re: [PATCH v8 4/4] cache-tree: Write updated cache-tree after commit

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 15, 2014, 06:38 UTC
Message-ID: <CAPc5daVH=i72Y4dA8TefPLfFB79Cvw7STPnQf_f10cBeYbg2ug@mail.gmail.com>
In-Reply-To: <CACsJy8BvQYyXWB7YfoonfEeqi9gStEZHqKC_JNAhxZbLJas54w@mail.gmail.com>

On Mon, Jul 14, 2014 at 7:15 PM, Duy Nguyen <pclouds@gmail.com> wrote:

Show 5 quoted lines

>
> It makes me wonder if a cleaner way of rebuilding cache-treei in this
> case is from git-add--interactive.perl, or by simply spawn "git
> update-index --rebuild-cache-tree" after running
> git-add--interactive.perl.

We could check if the cache-tree has fully been populated by "add -i" and limit the rebuilding by "git commit -p" main process, but if "add -i" did not do so, there is no reason why "git commit -p" should not do so, without relying on the implementation of "add -i" to do so.

At least to me, what you suggested sounds nothing more than a cop-out; instead of lifting the limitation of the API by enhancing it with reopen-lock-file, punting to shift the burden elsewhere. I am not quite sure why that is cleaner, but perhaps I am missing something.

In the longer run, it would be plausible that somebody would want to rewrite "git-add -i" and will make it just a C API call away without having to spawn a separate process. You cannot punt by saying "make 'add -i' responsible for it" at that point; you will be doing what 'add -i' would be doing yourself, no?