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

[Jakub Narebski <jnareb@gmail.com>]

"Stephen R. van den Berg" <srb@cuci.nl> writes:

> This is kind of confusing.
>
> 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.
> 
> 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.
> 
> I suggest two things:
> a. That during the cloning process, the grafts file is completely
>    disregarded in any case at first.
> 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?).

A bit of explanation: initially I think grafts were created as a means
to "graft" historical repository (conversion from BitKeeper and from
patches) to current work repository (from when git was deemed suitable
as SCM for Linux kernel development).  Nevertheless the machenism is
generic enough to change history _locally_ in many strange ways (for
example shallow clone uses kind of grafts).

Because graft file can be used to alter history, this totally
_bypases_ the check given by sha1 of commit and cryptographically
signed tags.  It negates security given by sha-1 signing.  That's why
using grafs must be _conscious_ decision - therefore they are purely
local and not propagated.

(Also there were no place for grafts in the "smart" trasport, i.e. git
and ssh protocols.  Thinking about what happens if both sides have
grafs files which differ...)

On the other hand history _without_ grafts might not validate.  I
think that it is why current confusing behavior...

-- 
Jakub Narebski
Poland
ShadeHawk on #git