Tags for both mercurial and git.

[Michael Forbes]

Is there a way to have a tag for both mercurial and git?  It seems that these are incompatible, but I don't know why they need to be:

$ hg tag -r main 0.1  # Tags will not be seen by git repos.
$ hg tag -r main --git 0.1
abort: the name '0.1' already exists
$ hg tag -fr main --git 0.1
abort: cannot move git tags
(the git documentation heavily discourages editing tags)

Is there any way to fix this retroactively?

Going the other way seems to work, but I don't know how to get here if I accidentally made the mercurial tag first:

$ hg tag -r main --git 0.1  # hg clones will not see this tag
$ hg tag -r main 0.1
abort: tag '0.1' already exists (use -f to force)
$ hg tag -fr main 0.1  # Now both hg and git see the tags.

Is there some way to tag both manually?  Should I be using something else like named branches?

[Dan Villiom Podlaski Christiansen]

I'm a bit curious as to why you assume that Mercurial tags aren't seen by Git? The way it should work is that:

* Mercurial tags are converted into (unannotated, unsigned) Git tags when pushing to Git.
* Git tags are represented as a special kind of local tag.

So if you want a tag in both places, create a Mercurial tag. Our documentation might very well be somewhat confusing/lacking, but that's the way it Should™ work 🙂

> --
> You received this message because you are subscribed to the Google Groups "hg-git" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hg-git+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hg-git/7bae3198-6458-4917-b995-25757410877cn%40googlegroups.com.

--

Dan Villiom Podlaski Christiansen
dan...@gmail.com — +45 2728 9771

[Uwe Brauer]

>>> "DVPC" == Dan Villiom Podlaski Christiansen <dan...@gmail.com> writes:

> I'm a bit curious as to why you assume that Mercurial tags aren't seen by Git? The way it should work is that:
> * Mercurial tags are converted into (unannotated, unsigned) Git tags when pushing to Git.
> * Git tags are represented as a special kind of local tag.

> So if you want a tag in both places, create a Mercurial tag. Our
> documentation might very well be somewhat confusing/lacking, but
> that's the way it Should™ work 🙂

BTW it seems impossible to delete a git tag, once it is set. I wonder whether this is by design or a bug.

[Michael Forbes]

That is what I expected, however, when I created the mercurial tags and then pushed to GitHub, the tags were not seen.  (See https://github.com/sphinx-contrib/zopeext/issues/6).

Here is a MNWE:

mkdir git-repo
cd git-repo
git init --bare
cd ..
hg clone git-repo hg-repo
cd hg-repo
touch A.txt
hg add A.txt
hg commit -m "A"
hg bookmark main

hg tag -r main 0.1

hg tag -r main --git 0.2
hg push -r .
cd ../git-repo
git tag

Only the 0.2 tag shows.

Maybe git tags are created but not pushed?

[Dan Villiom Podlaski Christiansen]

On 22 Dec 2022, at 19.28, 'Michael Forbes' via hg-git <hg-...@googlegroups.com> wrote:

> That is what I expected, however, when I created the mercurial tags and then pushed to GitHub, the tags were not seen. (See https://github.com/sphinx-contrib/zopeext/issues/6).
>
> Here is a MNWE:
>
> mkdir git-repo
> cd git-repo
> git init --bare
> cd ..
> hg clone git-repo hg-repo
> cd hg-repo
> touch A.txt
> hg add A.txt
> hg commit -m "A"
> hg bookmark main
> hg tag -r main 0.1
> hg tag -r main --git 0.2
> hg push -r .
> cd ../git-repo
> git tag
>
> Only the 0.2 tag shows.
>
> Maybe git tags are created but not pushed?

The culprit is the -r/--rev argument, it seems. You're pushing the commit that _created_ the tag rather than the tag itself. The coupling between names and commits is, generally speaking, much looser with Git than it is with Mercurial, so you can push a bunch of commits without pushing their names. Essentially, this is consistent with bookmarks where pushing a specific commit won't also push bookmarks on ancestor commits.

So, I think this is by design… the next question then becomes whether the design is correct 🙂

A slightly adjusted version:


+ rm -rf /tmp/xxx
+ mkdir -p /tmp/xxx
+ cd /tmp/xxx
+ mkdir git-repo
+ cd git-repo
+ git init --bare --quiet
+ cd ..
+ hg clone git-repo hg-repo
updating to branch default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
+ cd hg-repo
+ touch A.txt
+ hg add A.txt
+ hg commit -m A
+ touch B.txt
+ hg add B.txt
+ hg commit -m B
+ hg bookmark -r 0 old-main
+ hg bookmark main
+ hg push -r .
pushing to /private/tmp/xxx/git-repo
searching for changes
adding objects
added 2 commits with 2 trees and 1 blobs
adding reference refs/heads/main
+ hg tag -r main 0.1
+ hg tag -r main --git 0.2
+ hg push -r .
pushing to /private/tmp/xxx/git-repo
searching for changes
adding objects
added 1 commits with 1 trees and 1 blobs
updating reference refs/heads/main
adding reference refs/tags/0.2
+ hg log -r . -r 0.1 --style=compact
2[0.2,default/main,tip][main] c5cef8296e5c 2022-12-22 20:04 +0100 danchr
Added tag 0.1 for changeset 5f7d63f46952

1[0.1] 5f7d63f46952 2022-12-22 20:04 +0100 danchr
B

+ cd ../git-repo
+ git tag
0.2
+ hg -R ../hg-repo push -r 0.1
pushing to /private/tmp/xxx/git-repo
searching for changes
adding reference refs/tags/0.1
+ git tag
0.1
0.2

[Michael Forbes]

Thanks!  I was thinking about this from the mercurial standpoint: pushing -r . pushes .hgtags so I assumed this would also push the git tags.

From my perspective, this was non-intuitive and led to several issues.  Not sure if changing the design might cause other problems, but currently am thinking that it would be best for the git tags in .hgtags to be pushed by default.

On Thursday, December 22, 2022 at 11:08:04 AM UTC-8 dan...@gmail.com wrote:

On 22 Dec 2022, at 19.28, 'Michael Forbes' via hg-git <hg-...@googlegroups.com> wrote:

> That is what I expected, however, when I created the mercurial tags and then pushed to GitHub, the tags were not seen. (See https://github.com/sphinx-contrib/zopeext/issues/6).

...

[Michael Forbes]

One more comment suggesting that maybe a different design would be prudent:

...

hg push -r 0.1   # Does not push .hgtags since they are in the next commit.

cd ..

hg clone git-repo hg-repo1  # Has a tag for 0.1 since it is in git

hg clone hg-repo1 hg-repo2   # Pure mercurial repo does not have tag 0.1 since it does not have .hgtags

Thus, one must make sure to push both the 0.1 tag explicitly, and the current changeset:

hg push -r . -r 0.1

or, the following would probably be good practice:

hg push -r main -r 0.1   

But mercurial users are probably still going to make mistakes like I did, so I think the default should at least be to push all tags in .hgtags on behalf of the user.