Re: [PATCH] fast-export: Allow pruned-references in mark file

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