Re: Questions about the new

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