Re: performance problem: "git commit filename"

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 13, 2008, 19:31 UTC
Message-ID: <alpine.LNX.1.00.0801131416540.13593@iabervon.org>
In-Reply-To: <alpine.LFD.1.00.0801130850460.2806@woody.linux-foundation.org>

On Sun, 13 Jan 2008, Linus Torvalds wrote:

Show 13 quoted lines

> On Sun, 13 Jan 2008, Daniel Barkalow wrote:
> > 
> > The only issue I know about with using unpack_trees in C as a replacement 
> > for read-tree in shell is that unpack_trees leaves "deletion" index 
> > entries in memory which are not written to disk, but may surprise some 
> > code (these are used to allow -u to remove the files from the working 
> > tree).
> 
> I certainly agree that this patch should be double-checked. I'm pretty 
> sure the issue you mention wouldn't be an issue, since the end result is 
> only used for actually updating the index and writing it out as a tree 
> (both of which should handle the magic zero ce_mode case ok), but it would 
> certainly be good to walk through all cases.

Yeah, I didn't think it would be an actual problem, but verifying that requires looking outside of the context of the patch. It may even be worth putting in a comment for now, since I bet wt_status_print and run_status could be optimized in a way that would look perfectly reasonable (use the in-memory index, instead of reading a file) but would expose the magic case to the diff machinary, which (IIRC) doesn't handle it. But I agree (having now looked at the rest of builtin-commit) that the odd index entries can't escape, and this should be fine for 1.5.4.

	-Daniel
*This .sig left intentionally blank*