Fmt: Release tags cannot be used with git submodule

[Gachapen]

The release tags are not part of any branch, so if a git submodule refers to the commit of a release tag, it will be unable to check it out.

The only alternative solution I know of now is to run git submodule foreach --recursive 'git fetch --tags' before git submodule update --recursive, which just makes things harder than they should be.

The best solution would be to tag releases on the master branch, or commit releases in separate branches.

If I could I would just use master, but it contains breaking changes.

[Gachapen]

The 3.0.0 tag is on the master branch, so I ended up reverting to this version, but I'd like to be able to use the latest version.

[foonathan]

Can't you just add branch = <sha of commit> to your .gitmodule file?

[Gachapen]

No, it doesn't make any difference.

[foonathan]

Hm, it should.

I'm just going to create a branch at the 3.0.1 tag when I'm home, in around half an hour.

[Gachapen]

OK, thanks.

I tried both setting branch = 3.0.1 and branch = 7fa8f8fa48b0903deab5bb42e6760477173ac485, but it still couldn't checkout the commit.

Note that it will work if the submodule is initialized freshly, but not if you're running update on a submodule initialized before the 3.0.1 tag was created.

[foonathan]

I see.

For each X.Y.0 release, I can create a branch release-X.Y. If a patch is released, the commits will be merged on the release branch and the new release tagged on it.

This means that the 3.0.1 tag will be on release-3.0. If a 3.0.2 is released, it will be on this branch again.

Would that work for you?

[Gachapen]

Yes, that sounds perfect.

[nabijaczleweli]

Wait, what? branch = TAG works and well at that, see example

[foonathan]

Anyways, I've just create the release-3.0 branch.

[Gachapen]

What should I see from this example? I already tried that. Did you see my note in https://github.com/fmtlib/fmt/issues/412#issuecomment-258612347?

It is hard to create a reproducible example as it only happens if you initialized the submodule before the tag is created.

[Gachapen]

Thanks, @foonathan, it is working now:

$ git submodule update --init --recursive
From https://github.com/fmtlib/fmt
 * [new branch]      release-3.0 -> origin/release-3.0
 * [new tag]         3.0.1      -> 3.0.1
Submodule path 'third_party/fmt': checked out '7fa8f8fa48b0903deab5bb42e6760477173ac485'

[vkresch]

@foonathan So does it work or not? For me branch=TAG didn't work. I just use this solution with git checkout TAG.

[ohhmm]

@vkresch ,

https://stackoverflow.com/a/18797720/525578
Note: only branch name is supported in a .gitmodules file, but SHA and TAG are not supported! (instead of that, the branch's commit of each module can be tracked and updated using "git add .", for example like git add ./SubmoduleTestRepo, and you do not need to change the .gitmodules file each time)

Thanks,
Serg

[lili2012]

Wait, what? branch = TAG works and well at that, see example

I forked this repo and change
[submodule "audiere"]
path = ext/audiere
url = https://github.com/nabijaczleweli/audiere.git
branch = v1.9.4 ---> start
start is an existed tag. It still checkout v1.9.4. This means branch = tag is truly not available for now.