Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
