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

From: Antoine Pelisse <apelisse@gmail.com>
Date: Dec 1, 2012, 10:10 UTC
Message-ID: <CALWbr2yfBoMRSiRwUB04gjcPSypfMw5u+q2nGWw+e0GDTHzqUw@mail.gmail.com>
In-Reply-To: <7vobikqelo.fsf@alter.siamese.dyndns.org>

Show 5 quoted lines

> 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