Antoine Pelisse [off-list ref] writes:
quoted
I am not sure I follow the above, but anyway, I think the patch does
is safe because (1) future "fast-export" will not refer to these
pruned objects in its output (we have decided that these pruned
objects are not used anywhere in the history so nobody will refer to
them) and (2) we still need to increment the id number so that later
objects in the marks file get assigned the same id number as they
were assigned originally (otherwise we will not name these objects
consistently when we later talk about them).
I fully agree on (1), not so much on (2) though.
...
Both "commit mark :2" and "commit mark :3" end up being marked :2.
Any tool like git-remote-hg that is using a mapping from mark <-> hg changeset
could then fail.
Yeah, I think I agree that you would need to make sure that the
other side does not use the revision marked with :2, once you retire
the object you originally marked with :2 by pruning. Shouldn't the
second export show :1 and :3 but not :2? It feels like a bug in the
exporter to me that the mark number is reused in such a case.
Yeah, I think I agree that you would need to make sure that the
other side does not use the revision marked with :2, once you retire
the object you originally marked with :2 by pruning. Shouldn't the
second export show :1 and :3 but not :2? It feels like a bug in the
exporter to me that the mark number is reused in such a case.
It depends what you call a bug.
If the last item from the list is pruned, and no new objects
are exported, you will lose both reference and count to mark :2.
In this situation, incrementing last_idnum was pointless.
Assuming that we can't do anything about that, marks should be
considered mutable (and I don't think there is any way it
shouldn't). Then incrementing last_idnum is always useless.
Now, if marks can change, I don't understand why we use them at all.
(or don't provide the possibility to not use them at least).
In the "hg <-> git" case, it seems like an unecessary step:
hg revs <-> git marks <-> git sha1
Potentially forces the remote-helper to re-read the "marks <-> sha1"
everytime.
Also in the remote-helper, the "list" command requires sha1 for each
heads, while "import/export" can't work with sha1 but only marks, which
seems inconsistent.
My last point is about "git-remote-hg" and still mutable revs.
It seems like Felipe is using revs() rather than node() or hex() to
refer to mercurial changeset while those revs are also mutable, and
there exists immutable references: hex.
To sum up, the whole idea is, why would we use unsafe mutable marks
when we can use safer immutable references ?
Cheers,
Antoine