what happens is that the missing tags are conflicting tags, that is,
tags corresponding to states that are not really "replayed" when darcs
exports a repository to git.
We could enable these tags to be exported as git tags, but they would
not refer to any reliable state of the repository anyway.
We're aware this is a problem with darcs's export code and there are
some ideas about how to tacle this, see eg the second item of
So, as a short-term solution I think "darcs export" should at least
throw some warning message when the repository has conflicts. As for
whether we should export conflicting tags (ie, those that are
meaningless in the git mirror), I'm not sure yet.
Thanks for the explanation.
Can we run some command for detecting the conflicting tags before the
Can we make something in the Darcs repository for fixing the conflicting
I haven't looked at this example, but I think the basic problem is not
really with the tags themselves, but that the export command loses
information about the actual conflicts.
If you have patches A;B;C in a repo where B conflicts with A and C resolves
the conflict, then you'll lose information about what B would have done if
there hadn't been a conflict. As Guillaume says it would definitely be
sensible to print out a warning at that point.
The issue with tags is that if the tag included B but not A, there's no
state in the git repository that we can tag now.
Actually, that can happen even without a conflict - if we have X;Y in the
repo, then a tag that includes Y and not X won't have any analogue in the
linear git repo that darcs currently produces.
The solution to both problems is to produce non-linear git repos on export,
but that's more of a challenge to implement.