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 th
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 wa
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 beha
Junio C Hamano writes:
> Jeff King 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 4ea4acbcb09
Jeff King 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 4ea4acbcb0930ac42acc87a0d203864dec1a9697
> g
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 obje
6 matches
Mail list logo
