On Fri, 2007-11-09 at 17:24 +0000, Johannes Schindelin wrote: > Hi, > > On Fri, 9 Nov 2007, Kristian H?gsberg wrote: > > > On Fri, 2007-11-09 at 17:05 +0000, Johannes Schindelin wrote: > > > > > On Fri, 9 Nov 2007, Kristian Høgsberg wrote: > > > > > > > This fixes the race in the last test int t3700. > > > > > > Well, it is not a race. My fault. I thought it was. > > > > > > What you basically did was to make sure that the index is up-to-date > > > after adding the files. You might even want to say that in the commit > > > message, and only then say that it fixes t3700, too. > > > > OK, I guess what I was wondering was why write_cache() doesn't write out > > an up-to-date index. > > write_cache() only writes the index, it does not update it. > > > Do we need a call to refresh_cache() when we update the user cache but > > commit an index created from read_tree+add_files? I.e. after the > > add_files_to_index() call on line 97? The shell script doesn't do this, > > it only runs update-index --refresh for the index that gets committed. > > I think it would be sane to do so. > > IIUC this basically means that "git add <file> && git commit" should do > the same to the cache as "git commit <file>". No, that's equivalent to "git commit -i <file>". If you just say "git commit <file>", that will create a temporary index initialized to HEAD, add file to that index and the regular (user) index, and then commit the temporary index file. The shell script doesn't refresh the regular index in this case. I think it makes sense to add that, but it will be a subtle difference in behaviour. cheers, Kristian - 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
