GitPython
GitPython copied to clipboard
Getting the latest tag of a remote repo
The following is from a question on StackOverflow I've asked some time ago:
I'd like to be able to check what's the latest tag for a given repo (I'm using CPython here as an example).
The following works:
g = git.cmd.Git()
blob = g.ls_remote('https://github.com/python/cpython', sort='-v:refname', tags=True)
blob.split('\n')[0].split('/')[-1]
and yields 'v3.9.0a6' because the blob looks something like this:
'bc1c8af8ef2563802767404c78c8ec6d6a967897\trefs/tags/v3.9.0a6\ndcd4 (...)'
Someone suggested I can contribute this solution to gitpython
and someone else suggested that the git ls-remote
is pretty stable and well documented so parsing its output might be the right way to go when trying to get the latest tag of a remote repo.
My question: would you like me to contribute this type of functionality? And if so, I'd appreciate a hint on where should it be / how it should be named / anything else.
This seems like something more people could benefit from, and I would be glad to see a PR. You could mark it as draft and play around with different APIs until it feels right.
If the lines above a representative for a usecase, it could be a free function, otherwise it could (also) be a method on the Repo
type. However, it's really up to you to find something that feels right for the usecase - I don't think I would be pedantic about it 😅.
Awesome, thanks 👍 I'll give it a try tomorrow.
We're using semantic versioning in our repo (like v1.2.3). The following line of code has been working for us for a long time:
source_repo_tags = natural_sort(list(map(lambda t: str(t), Repo(BASE_DIR).tags)))
[ t for t in source_repo_tags if re.compile('^v\d+\.\d+\.\d+$').match(t) ][-1]
However, it stopped working as of two days ago - now that list is empty even if we still have all these tags in the repo.
I agree that a dedicated method would be good.
@alpozcan GitPython does this using this snippet of code effectively with refs/tags
as prefix to filter the references. In line 625 it could fail silently on individual paths, but shouldn't fail all of them.
Even though it understands packed refs, maybe something changed with the format making it fail silently here. Maybe it would already help to add debug-logging to these portions instead of skipping them silently. A PR would of course be welcome for that.
Thank you
Any update on this?
I haven't found the time then, sorry.
@Wyko maybe you'd be interested in creating a PR for this feature?