Hi, On Sun, 17 Feb 2008, Junio C Hamano wrote: > 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. Well, my workflow has lots of these moments. I do not even feel "oops" about it. More like "by the way, this needs committing _now_". So I guess I'll be the guinea pig for this patch, and if it is too painful, I'll just go and fix it. Ciao, Dscho - 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
