Re: Questions about the new

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Oct 12, 2009, 12:19 UTC
Message-ID: <4AD31EBF.6090307@viscovery.net>
In-Reply-To: <loom.20091012T115746-719@post.gmane.org>

Sergio schrieb:

> 1) Grafts and replace entries seem to operate on different aspects of the
> history graph. Grafts operate on arcs and replace on nodes.

Correct, but see below about tree and blob objects.

> As such, replace entries seem less general to me.

With grafts you can only change parenthood; with replace entries you can change parenthood *and* all other aspects of a commit (message, author, committer, dates).

Hence, replace entries are more general than grafts.

> Apparently, to simulate a graft with replace entries, you need to introduce
> extra commit objects. For instance, if object B has no parents, to pretend that
> it derives from some A, one needs to create an object B' equivalent to B but
> for the parents and then replace B by B', is this right?

Yes. Use git-cat-file + edit + git-hash-object as explained in this message just the other day: http://thread.gmane.org/gmane.comp.version-control.git/129727/focus=129907

> Conversely, I guess
> you can always simulate a replace entry with the graft mechanism, without the
> need to add any extra commit object. Am I overlooking something?

You cannot; see above. You can even replace tree objects and blob objects using replace entries, IIUC, but you cannot do that with grafts.

> 2) Is it currently possible to use a replace entry to replace a commit object
> with nothing? Namely if B has A as its sole parent, is it possible to have a
> replace entry such as A-sha1 becomes null, to pretend that B is a hierarchy
> root?

Sure. Just make a commit object that does not have parents.

> 3) If I remember correctly, there was a reason why grafts were not considered
> suitable for transferring across repos. Can someone remind me about it? How
> does the replace mechanism address this issue?

The problem with grafts was that, for example, git-pack-objects obeyed the graft, and could create a broken repository by removing grafted-away objects. And since git-fsck also obeyed the graft, it did not notice the breakage.

OTOH, history walkers (upload-pack, send-pack, pack-objects) and fsck never obey replace entries in the history. But they do keep track of them (and the history that they reference) because they are referenced from the refs/replace namespace.

-- Hannes