Re: grafts+repack+prune = history at danger

[Johannes Sixt <J.Sixt@eudaptics.com>]

Junio C Hamano wrote:
> 
> Johannes Sixt <J.Sixt@eudaptics.com> writes:
> 
> > Sure, if I connect my linux repo with a graft to the historical BK tree,
> > then toss the ref that pointed to the historical tree, then git prune:
> > - then currently it won't prune the historical tree
> > - but under my proposal it would. Silly me. Why did I remove that ref?
> 
> [...]
> 
> Thankfully, the real git does not behave that way.  That is why
> fsck/prune _must_ honor grafts.  That makes the locally altered
> view consistent.  To the altered world view, what are stored in
> the object database do not change, but your view of how they are
> connected does.  And if your altered view thinks commit
> v2.6.12-rc2 has one of the commits in the bkcvs history as its
> parent, you do not want to lose that history merely because you
> lost a ref to it -- as long as the commit tagged as v2.6.12-rc2
> is reachable, its (imaginary) parent should be as well.

>From your argument I deduce that grafts are a very important thing (once
they exist in a repo). But the current implementation does not honor
this:

- the grafts file is not part of the objects database
- it is manipulated manually instead of by tools the check for errors
- it is not transferred across clones/pulls/pushes (it's even possible
to create an inconsistent clone)

The way out that I see is to make grafts much, much less important.
Namely that they are obeyed _only_ by tools that _present_ the database
contents. All manipulators must disregard grafts.

Consequently, if I install grafts, I must make sure that I don't prune
away objects that the grafted history needs (i.e. avoid the silliness
mentioned above). If I happen to make the grafted history inconsistent,
I can make it consistent again by removing the grafts file (it was a
local thingy anyway) - no harm done - just the _presentation_ was
altered.

-- Hannes