1. Summarise the issue (what were doing, what went wrong?)

The repository http://code.haskell.org/zlib/ has 19 tags

$ darcs show tags | wc -l
19

but 

$ darcs convert export | (cd ../mirror && git fast-import)
...
Total objects:
 tags : 16

only exports 16 tags.

The missing tags were turned in Git comments (see
https://github.com/haskell/zlib/issues/1).

3. What darcs version are you using? (Try: darcs --exact-version)

$ git --version
git version 2.5.1

$ darcs --exact-version
darcs compiled on Sep  1 2015, at 16:34:50

Context:

[TAG 2.10.1
Guillaume Hoffmann <guillaumh@gmail.com>**20150709164849
 Ignore-this: 91f5dd97c5899801364cdfc0a8266faa
] 

Compiled with:

HTTP-4000.2.20
array-0.5.1.0
attoparsec-0.13.0.1
base-4.8.1.0
base16-bytestring-0.1.1.6
binary-0.7.5.0
bytestring-0.10.6.0
containers-0.5.6.2
cryptohash-0.11.6
data-ordlist-0.4.7.0
dataenc-0.12
directory-1.2.2.0
filepath-1.4.0.0
hashable-1.2.3.3
haskeline-0.7.2.1
html-1.0.1.2
mmap-0.5.9
mtl-2.2.1
network-2.6.2.1
network-uri-2.6.0.3
old-time-1.1.0.3
parsec-3.1.9
process-1.2.3.0
random-1.1
regex-applicative-0.3.2.1
regex-compat-tdfa-0.95.1.4
tar-0.4.2.1
terminfo-0.4.0.1
text-1.2.1.3
time-1.5.0.1
transformers-0.4.2.0
transformers-compat-0.4.0.4
unix-2.7.1.0
unix-compat-0.4.1.4
utf8-string-1.0.1
vector-0.10.12.3
zip-archive-0.2.3.7
zlib-0.6.1.1

4. What operating system are you running?

Ubuntu 12.04

Hi Andrés,

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
<http://darcs.net/GSoC#better-conflicts-handlingui> .

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.

Hi Guillaume,

Thanks for the explanation.

Can we run some command for detecting the conflicting tags before the
conversion?

Can we make something in the Darcs repository for fixing the conflicting
tags?

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.

I guess the clean solution would be to

(1) create a branch for each unclean tag

(2) create branches and merger commits for each conflict