On Wed, Aug 14, 2013 at 11:39:34AM -0700, Junio C Hamano wrote:
Older versions of JGit used to put duplicate objects in a pack, and
IIRC Shawn declared that a bug in the packer and fixed it, so from
that point of view, I think rejecting is probably the right thing,
even though I think
I'm tracking down a rather odd problem in a packfile I found on GitHub.
This particular packfile contains the same object at various offsets
within the file. In fact there are several packfiles that exhibit this
behavior, all in the same repository, and in each one there are several
duplicated
Jeff King p...@peff.net writes:
lookup does not. It hits an assert() that can only be triggered in the
face of duplicate objects. For example:
$ git cat-file -t 4ea4acbcb0930ac42acc87a0d203864dec1a9697
commit
$ GIT_USE_LOOKUP=1 git cat-file -t
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
lookup does not. It hits an assert() that can only be triggered in the
face of duplicate objects. For example:
$ git cat-file -t 4ea4acbcb0930ac42acc87a0d203864dec1a9697
commit
$ GIT_USE_LOOKUP=1 git cat-file
On Wed, 14 Aug 2013, Jeff King wrote:
1. Is sha1_entry_pos wrong to barf on duplicate items in the index? If
so, do we want to fix it, or simply retire GIT_USE_LOOKUP?
I'd think that sha1_entry_pos should be more lenient here, especially if
this doesn't compromize the overall git
On Wed, 14 Aug 2013, Junio C Hamano wrote:
Also repacking may have a funny corner case. I do not recall the
details as the above was a long time ago, but when I was tracking it
down, a delta was made against one copy of the base object, and
referred to it using delta-offset, while there was
6 matches
Mail list logo
