On Mon, Jul 14, 2014 at 7:15 PM, Duy Nguyen <pclo...@gmail.com> wrote:
> 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
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
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?
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