fix: refetching lightweight tags from origin

[miki725]

• Followed the steps in the contributor's guide: https://crashoverride.com/docs/other/contributing#filing-the-pull-request
• PR title uses semantic commit messages
• Filled out the template to a useful degree
• Updated CHANGELOG.md if necessary

Issue

fixes #345

Description

If repo is checked out incorrectly locally, a tag can be lightweight but annotated in origin. To guarantee chalk sees up-to-date tags, chalk refetches lightweight tags to ensure it reports correct metadata about the "latest" tag.

This was noticed via checkout github action which if triggered from a tag build it looses any tag annotations.

Testing

➜ make tests args="test_git.py::test_refetch_tag --logs --pdb"

[ee7]

If the same commit has two tags:

• an annotated tag 0.1.0
• and a lightweight tag 0.1.1

I guess we do want to report the details for 0.1.0? That's the current behavior, and I'm OK with that.

[miki725]

so far annotated tags have a preference over lightweight tags as they have a concrete ordering without doing any tag name comparisons as tag formats are wildly different with semver, dates, etc so nothing concrete to sort by. if there are no annotated tags then it falls back to regular tags

[ee7]

For later: maybe we should think about not hard-coding origin?

[miki725]

hmm let me see if we figure out the correct remote name in the parsing although we might still want to hardcode to origin as thats standard in CI and locally people might have all sort of remotes. not sure. your thoughts?

[ee7]

Might be worth parsing e.g. git remote or git remote -v and, when both:

• there is only one remote
• the only remote is not named origin

we use that remote.

For the case where there are multiple remotes and none are named origin, I don't know. But that's probably not very important.

[ee7]

As an n=1, personally, I prefer to name every remote explicitly. So if I have a fork on GitHub of repo foo from org, I typically have:

• A remote named ee7 that tracks https://github.com/ee7/foo
• A remote named org that tracks https://github.com/org/foo

and when I don't maintain a fork, there's only one remote:

• A remote named org that tracks https://github.com/org/foo

That is, no origin, and it's always clear where I'm pushing.

And furthermore, in my git config I have:

[push]
    default = nothing

So that:

$ git push
fatal: You didn't specify any refspecs to push, and push.default is "nothing".

But yes, in most situations for chalk, assuming origin is probably OK most of the time. But it's not guaranteed to be correct.

Probably better to think about this later - there's probably things that are affected outside this PR.

[miki725]

yep. if we make that generic prolly worth adding additional keys like GIT_REMOTE_NAME or something as we currently have ORIGIN_URI which I guess presumes origin although the git config parsing uses first remote if origin is not found

chalk/src/plugins/vctlGit.nim

Lines 704 to 715 in cd68f2d

	for (sec, subsec, kvpairs) in conf:
	if sec == ghRemote:
	if subsec == ghOrigin:
	for (k, v) in kvpairs:
	if k == ghUrl:
	self.origin = v
	return v
	elif firstFound == "":
	for (k, v) in kvpairs:
	if k == ghUrl:
	firstFound = v
	break

[miki725]

actually you can pass a url to git fetch command directly so will use that for now. this way it will use whatever remote chalk detects otherwise...

[miki725]

for reference:

chalk/src/plugins/vctlGit.nim

Line 588 in cd68f2d

let sortedTags = info.tags.values().toSeq().sortedByIt((it.unixTime, it.name))