> 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"
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
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 ?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html