Thanks Johannes for all the detailed explanations
Johannes Sixt <j.sixt <at> viscovery.net> writes:
>
> 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.
OK, the replace mechanism also can replace a blob object or a tree.
My focus was on commit objects only.
>
> > 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.
Limiting the discussion to commit objects, I think there are two
possible scenarios.
1) You create new commits objects as needed
2) You do not.
If you follow 1), I believe grafts and replace entries have exactly the same
flexibility.
If I happen not to like commit B in A---B---C and I want A---B'---C
where B' has
completely different aspects from B I can either replace B by B' or
graft away
B, pretending that the parent of A is B
But there are many things that can be done with grafts merely adding a graft
(e.g. cutting away a part of history, joining history), that cannot be done
with replace entries without creating new commits objects.
I was asking because I was wandering whether replace entries were first
or later
meant to make grafts deprecated. I hope not, because for a few things
working on
arcs seems still nice.
> > 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 >
> 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
Thanks, good pointer. I missed this!
> > 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.
Well, I meant for what regards commit objects only.
If I want to replace some commit X by some commit X' I merely need to
modify the
parent information of all the commits that are child of X so that they
pretend
to be child of X', or am I missing something?
> You can even replace tree objects and blob objects
> using replace entries, IIUC, but you cannot do that with grafts.
Definitely right!
> > 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.
OK, you need to create a new commit object. At the beginning for some
reason I
thought that you could replace an object
with "nothing" or 00000000000000000000000000000000000000000000
> > 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.
>
Thanks for the explanation. Can this be made possible for grafts too?
Wouldn't
it be a matter of having history walkers never obey grafts but keep track of
them (i.e. of the history of the parenthood they reference)?
Like we have "annotated" or heavyweight tags living as objects in the
database,
would it be possible or make sense to have annotated grafts or replace
entries,
so that one can express why, by whom and when history was changed?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html