Bug 178258 – [GTK] jhbuild does not fetch new tags

• Status: NEW
• Component: WebKitGTK

[Alicia Boya García]

I found this problem when updating the jhbuild:


*** Checking out fonts *** [9/46]
git remote set-url origin https://github.com/WebKitGTK/webkitgtk-test-fonts.git
git remote update origin
Fetching origin
git checkout 0.0.7
error: pathspec '0.0.7' did not match any file(s) known to git.


The tag existed in the remote repository but it was not fetched locally.

[Alicia Boya García]

This is caused by the `git remote update origin` command that does not seem to
(always) update tags, though it does in other projects (e.g. GStreamer) for
reasons I don't know.

I'm uploading a tarball of my local clone of the repository right before the
problem was reproduced. You can move it to a temporary directory and run these
commands to confirm this is the source of the problem:

> tar xf webkitgtk-test-fonts.tar.gz
> cd webkitgtk-test-fonts
> git remote update origin
Fetching origin
remote: Counting objects: 15, done.
remote: Total 15 (delta 2), reused 2 (delta 2), pack-reused 13
Unpacking objects: 100% (15/15), done.
From https://github.com/WebKitGTK/webkitgtk-test-fonts
   8b9eed0..3968ea8  master     -> origin/master

This is not a problem if the local repository is updated with `git fetch --tags`:

> cd ..
> rm -rf webkitgtk-test-fonts
> tar xf webkitgtk-test-fonts.tar.gz
> cd webkitgtk-test-fonts
> git fetch origin --tags
remote: Counting objects: 19, done.
remote: Total 19 (delta 4), reused 4 (delta 4), pack-reused 15
Unpacking objects: 100% (19/19), done.
From https://github.com/WebKitGTK/webkitgtk-test-fonts
   8b9eed0..3968ea8  master     -> origin/master
 * [new tag]         0.0.7      -> 0.0.7

[Alicia Boya García]

Created attachment 323662 [details]
Dump of the repository before the update

[Alicia Boya García]

Created attachment 323663 [details]
Patch

[Adrian Perez]

Comment on attachment 323663 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=323663&action=review

Informal review: r+

> Tools/jhbuild/jhbuild-wrapper:66
> +    process = subprocess.Popen(['git', 'fetch', 'origin', '--tags'], cwd=jhbuild_source_path)

I am quite sure this change is the proper thing to do here.

[Carlos Garcia Campos]

Comment on attachment 323663 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=323663&action=review

>> Tools/jhbuild/jhbuild-wrapper:66
>> +    process = subprocess.Popen(['git', 'fetch', 'origin', '--tags'], cwd=jhbuild_source_path)
> 
> I am quite sure this change is the proper thing to do here.

I don't think it is, this is only used to download jhbuild itself, then it's jhbuild the one downloading the rest of the modules. So, this doesn't affect how other modules (like fonts) are fetched.

[Alicia Boya García]

Oh, right...

[Michael Catanzaro]

This seems like a bug in jhbuild itself, not our scripts, right?

Were you using jhbuild-wrapper manually? Obviously this could never occur when running update-webkitgtk-libs, since the entire repo would be cloned from scratch.

[Michael Catanzaro]

Looking at git-fetch(1), it seems this problem only occurs if the tag is not in the history of the branch being fetched. Indeed, Carlos forgot to push the webkitgtk-test-fonts 0.0.7 commit to master. So that would be good to do.

I agree that we need to use 'git fetch --tags', though. I think you just need to edit jhbuild/versioncontrol/git.py (in a patch on GNOME Bugzilla) and then update the jhbuild-wrapper script with the new jhbuild commit hash to download once it lands.

[Carlos Garcia Campos]

(In reply to Michael Catanzaro from comment #8)
> Looking at git-fetch(1), it seems this problem only occurs if the tag is not
> in the history of the branch being fetched. Indeed, Carlos forgot to push
> the webkitgtk-test-fonts 0.0.7 commit to master. So that would be good to do.

Oh! I pushed the tag but not the commit itself :-( I've just done so.

> I agree that we need to use 'git fetch --tags', though. I think you just
> need to edit jhbuild/versioncontrol/git.py (in a patch on GNOME Bugzilla)
> and then update the jhbuild-wrapper script with the new jhbuild commit hash
> to download once it lands.

Well, I guess this only happens when someone forgets to push the commits and pushes the tag only, like me, quite unlikely to happen, so I'm not usre it's worth patching jhbuild.

[Michael Catanzaro]

I'm not sure, but I think it could also happen if the tag is simply not on the history of the master branch. (Right? Or does it check all branches?)