Re: grafts+repack+prune = history at danger

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 26, 2007, 15:55 UTC
Message-ID: <Pine.LNX.4.64.0701260747110.25027@woody.linux-foundation.org>
In-Reply-To: <7vr6ti183o.fsf@assigned-by-dhcp.cox.net>

On Fri, 26 Jan 2007, Junio C Hamano wrote:

Show 6 quoted lines

> 
> One thing you could do is to take the local-ness of grafts more
> literally and enforce it more strictly by dropping grafts while
> fetch-pack and receive-pack exchange common objects and spawn
> pack-objects to come up with objects needed to be sent.  But
> because we currently punt, we do not even do that.

One option might be:

 - add a global flag (like the current "save_commit_buffer") that commands 
   can set to specify whether they want to honor grafts or not.

   The "please_follow_grafts" flag defaults to 1.

 - "git send-pack" would explicitly set it to zero, and thus we'd always 
   send a non-grafted result.

 - "git prune" would *also* explicitly set it to zero, but would also 
   manually look at the grafts file, and mark anything that is set in the 
   grafts file as being reachable (the same way it does for index entries 
   etc).

It might also be an option to then do:

 - "git repack" should probably also set it to zero - I think we might be 
   better off packing any grafted data separately.

The alternative, of course, is to try to transfer the grafts file for clones and fetches, but that is likely to be a *bad* idea. It's even a potential security issue: grafts can literally be used to short-circuit some of the inherent safety in git, in that an attacker can make a graft that makes history *look* fine, but hide part of it (you can't "really" hide history, but you can make normal git operations like "git log" basically ignore it by judicious use of grafts).

			Linus