Re: To graft or not to graft... (Re: Recovering from repository corruption)

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 11, 2008, 23:39 UTC
Message-ID: <alpine.LFD.1.10.0806111635200.3101@woody.linux-foundation.org>
In-Reply-To: <20080611232126.GA9054@cuci.nl>

On Thu, 12 Jun 2008, Stephen R. van den Berg wrote:

Show 6 quoted lines

>
> As I understood it from the few shreds of documentation that actually
> mention the grafts file, the grafts file is *not* being cloned.
> Therefore, my assumption was that cloning a repository that has a grafts
> file gives an identical result to cloning the same repository *without*
> the grafts file present.

That would probably be the right behaviour, but no - all our commit walkers honor the grafts file.

Including the ones used for creating pack-files and thus a clone.

> As I understand it now, the cloning process actually peeks at the grafts
> file while cloning, and then doesn't copy it.  This results in a rather
> confusingly corrupt clone.

Yes. The grafts-file was a mistake, but it's just barely useful to some people that it's stayed alive. Sadly, those "some people" don't tend to care enough about the problems it can cause.

> I suggest two things:
> a. That during the cloning process, the grafts file is completely
>    disregarded in any case at first.

Yes.

And (a'): git-fsck and repacking should just consider it to be an _additional_ source of parenthood rather than a _replacement_ source.

> b. Preferably the grafts file is copied as well (after cloning).  I
>    never really understood why the file is not being copied in the first
>    place (anyone care to explain that?).

The grafts file isn't part of the object stream and refs, and clones (and fetches) very much just copy the object database.

		Linus