When we read a sha1 file, we first look for a packed
version, then a loose version, and then re-check the pack
directory again before concluding that we cannot find it.
This lets us handle a process that is writing to the
repository simultaneously (e.g., receive-pack writing a new
pack followed by
On Thu, Aug 29, 2013 at 9:10 PM, Jeff King p...@peff.net wrote:
When we read a sha1 file, we first look for a packed
version, then a loose version, and then re-check the pack
directory again before concluding that we cannot find it.
This lets us handle a process that is writing to the
Jeff King p...@peff.net writes:
When we read a sha1 file, we first look for a packed
version, then a loose version, and then re-check the pack
directory again before concluding that we cannot find it.
This lets us handle a process that is writing to the
repository simultaneously (e.g.,
On Thu, Aug 29, 2013 at 09:17:57PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
When we read a sha1 file, we first look for a packed
version, then a loose version, and then re-check the pack
directory again before concluding that we cannot find it.
This lets us handle a
On Thu, Aug 29, 2013 at 09:10:52PM -0400, Jeff King wrote:
In the case of git-fsck, which uses the
DO_FOR_EACH_INCLUDE_BROKEN flag, this will cause us to
erroneously complain that the ref points to an invalid
object. But for git-repack, which does not use that flag, we
will skip the ref
5 matches
Mail list logo
