threads / discuss / 27892

RFC: Should git gc/repack respect .git/refs/replace?

Subject: RFC: Should git gc/repack respect .git/refs/replace?

## tl;dr

4 messages between Jul 23, 2011 and Jul 23, 2011.

replies: 3people: 3as markdown or json

Jon Seymour· Jul 23, 2011, 08:39 UTC · lore
I recently damaged a USB drive containing an archive of a finished project.

I am able to paper over a week of missing history by using the git replace mechanism, so that git rev-list now works as expected.

When I run git gc or git repack, I get the following:
   error: Could not read 023a1d5d3977420ba041cb556c0eee17c326aeb6
   fatal: Failed to traverse parents of commit
44d578ea81f7a90989e2ee3c676f50e3aff7071f

where 0bbded9a764d9f4c8dc27b778f70d044df65f65f is one of the missing commits I replaced with:

   git replace 023a1d5d3977420ba041cb556c0eee17c326aeb6
238d237db9137b4eaf96f1d554bf2668729b9b93

Is this expected behaviour? I had assumed that git repack would respect the topology implied by git replace.

Some other differences:
    git cat-file commit 023a1d5d3977420ba041cb556c0eee17c326aeb6

produces the expected output (that is the same as git cat-file commit 238d237db9137b4eaf96f1d554bf2668729b9b93), but

   git cat-file commit -t 023a1d5d3977420ba041cb556c0eee17c326aeb6
fails with:
   error: unable to find 023a1d5d3977420ba041cb556c0eee17c326aeb6
   fatal: git cat-file 023a1d5d3977420ba041cb556c0eee17c326aeb6: bad file

In my view, it seems reasonable that git repack should tolerate repos that have replace references in them otherwise you can never recover unused space.

Thoughts?
jon.
Andreas Schwab· Jul 23, 2011, 09:20 UTC · re: Jon Seymour · lore

Re: RFC: Should git gc/repack respect .git/refs/replace?

Jon Seymour <jon.seymour@gmail.com> writes:
Show 10 quoted lines
> I recently damaged a USB drive containing an archive of a finished project.
>
> I am able to paper over a week of missing history by using the git
> replace mechanism, so that git rev-list now works as expected.
>
> When I run git gc or git repack, I get the following:
>
>    error: Could not read 023a1d5d3977420ba041cb556c0eee17c326aeb6
>    fatal: Failed to traverse parents of commit
> 44d578ea81f7a90989e2ee3c676f50e3aff7071f
git-replace(1):
       Replacement references will be used by default by all git commands
       except those doing reachability traversal (prune, pack transfer and
       fsck).

This is required, since the replaced objects are not supposed to be recycled. If you want to make the replacements permanent use git filter-branch.

Andreas.
-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Jon Seymour· Jul 23, 2011, 09:25 UTC · re: Andreas Schwab · lore

Re: RFC: Should git gc/repack respect .git/refs/replace?

On Sat, Jul 23, 2011 at 7:20 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
Show 19 quoted lines
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> I recently damaged a USB drive containing an archive of a finished project.
>>
>> I am able to paper over a week of missing history by using the git
>> replace mechanism, so that git rev-list now works as expected.
>>
>> When I run git gc or git repack, I get the following:
>>
>>    error: Could not read 023a1d5d3977420ba041cb556c0eee17c326aeb6
>>    fatal: Failed to traverse parents of commit
>> 44d578ea81f7a90989e2ee3c676f50e3aff7071f
>
> git-replace(1):
>
>       Replacement references will be used by default by all git commands
>       except those doing reachability traversal (prune, pack transfer and
>       fsck).
>
Oops. Missed that - thanks.
> This is required, since the replaced objects are not supposed to be
> recycled.  If you want to make the replacements permanent use git
> filter-branch.
Ah, makes sense.
jon.
Jakub Narebski· Jul 23, 2011, 09:22 UTC · re: Jon Seymour · lore

Re: RFC: Should git gc/repack respect .git/refs/replace?

Jon Seymour <jon.seymour@gmail.com> writes:
Show 19 quoted lines
> I recently damaged a USB drive containing an archive of a finished project.
> 
> I am able to paper over a week of missing history by using the git
> replace mechanism, so that git rev-list now works as expected.
> 
> When I run git gc or git repack, I get the following:
> 
>    error: Could not read 023a1d5d3977420ba041cb556c0eee17c326aeb6
>    fatal: Failed to traverse parents of commit
> 44d578ea81f7a90989e2ee3c676f50e3aff7071f
> 
> where 0bbded9a764d9f4c8dc27b778f70d044df65f65f is one of the missing
> commits I replaced with:
> 
>    git replace 023a1d5d3977420ba041cb556c0eee17c326aeb6
> 238d237db9137b4eaf96f1d554bf2668729b9b93
> 
> Is this expected behaviour? I had assumed that git repack would
> respect the topology implied by git replace.
This is the expected behavior.

Replace mechanism is meant to be transferable and safe wrt. repacking. Therefore repack should not remove commits hidden by replacement objects, otherwise if you push to repository instance that doesn't have replace refs, you would get corrupt repository.

As replace mechanism uses ordinary refs, therefore replaced object are safe against repacking / pruning and transferrable in the same way as other refs.

If you want paper over missing history, you need to use GRAFTS, not replace objects.

Show 9 quoted lines
> 
> Some other differences:
> 
>     git cat-file commit 023a1d5d3977420ba041cb556c0eee17c326aeb6
> 
> produces the expected output (that is the same as git cat-file commit
> 238d237db9137b4eaf96f1d554bf2668729b9b93), but
> 
>    git cat-file commit -t 023a1d5d3977420ba041cb556c0eee17c326aeb6
Errr... isn't it
     git cat-file -t 023a1d5d3977420ba041cb556c0eee17c326aeb6
Show 5 quoted lines
> 
> fails with:
> 
>    error: unable to find 023a1d5d3977420ba041cb556c0eee17c326aeb6
>    fatal: git cat-file 023a1d5d3977420ba041cb556c0eee17c326aeb6: bad file

Hmmm... that looks like bug, assuming that you didn't make mistake in writing command.

BTW. do git-cat-file respect replace object, or is it only git-show
that respect them?
 
> In my view, it seems reasonable that git repack should tolerate repos
> that have replace references in them otherwise you can never recover
> unused space.

Replace are not meant for this. You can use grafts instead, but they are not transferable in-band, so forget about sharing repository if you do surgery on it like that...

-- 
Jakub Narebski

← back to recent threads