Re: [PATCH 0/3] null sha1 in trees

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jul 29, 2012 at 03:15:11PM -0700, Junio C Hamano wrote:

> All looked reasonable, even though I'd want to read the
> surrounding codepath over for 2/3 a few more times.
> 
> Will queue; thanks.

Yeah, 2/3 is the one that gives me the most pause. I originally assumed
we would never want to put a null-sha1 entry into the in-core index, but
that turned out to be very wrong. So I softened my assumption to "we
would never want to put a null-sha1 entry on disk". Which seems like the
right thing to me and passes the test suite, but there might be an
unexercised code path in there.

In an ideal world, I would trace each code path that inserts a cache
entry all the way back to its original sha1, but when I tried it turned
out too complex. The educated-guess-and-see-if-it-passes-tests approach
to coding does not make me happy, but I don't see a good alternative.

Patch 1 is a pure bug-fix, and it would be nice for it to make it onto a
maint- track or into 1.7.12 (though I can't guarantee that I got it 100%
right, I am confident that it is at least trying to do the right thing,
and any fixes would be incremental on top).  The other two should be
fine to cook longer and go in post-1.7.12.

-Peff
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]