Subject: Re: What's in git.git (stable)

From: Junio C Hamano <[email-masked]>
Date: Sun, 17 Feb 2008 17:31:05 -0800

Johannes Schindelin <[email-masked]> writes:

> On Sun, 17 Feb 2008, Junio C Hamano wrote:
>
>> The more fundamental improvement was along the lines of what I suggested 
>> soon after Kristian's initial round was posted, but what the current 
>> code does is not wrong nor hack.  It is about a partial commit after all 
>> and is not performance critical either.
>
> You mean: at this point, it is not necessary to be careful about the 
> index, as the index that will be reloaded will already have the most 
> recent timestamps, right?

I do not understand the question, but if you are referring to my
"not performance critical", I meant: "A partial commit is
never performance critical".

A partial commit is by its nature "oops, I earlier told you to
git add this and git add that but I did not mean that, eh, I do
mean it but not for this commit yet, sorry, I want to commit
changes to these paths first please and then I'll deal with the
earlier added paths in later commit perhaps.", i.e. very
interactive.  Its performance requirement is unlike an automated
script slurping hundreds of changes per minute applying exactly
the change it wants in each commit to the index and making
commits in rapid succession.