git_checkout fails to fetch new tags

[Longsueynin]

For example, having a repository with tag myTag and running Tiltfile with the following content works as expected:

git_checkout(
    repository_url='[email protected]/path/to/repo.git#tags/myTag,
)

Now, if a new tag myNewTag is added to the repository and the Tiltfile content is changed to:

git_checkout(
    repository_url='[email protected]/path/to/repo.git#tags/myNewTag,
)

Tilt will fail with:

stderr: "error: pathspec 'myNewTag' did not match any file(s) known to git\n"

This seems to be due to how the git config is populated after the initial git clone:

[remote "origin"]
	url = [email protected]/path/to/repo.git
	fetch = +refs/tags/myTag:refs/tags/myTag

On subsequent runs, git_checkout will perform git fetch --append which won't bring in the new myNewTag tag.

[nicksieger]

Looks like this is because git_checkout with the #branch or #tags/tag suffix uses the --branch tag to git clone. Although perhaps not as it was intended to be used, does specifying the repository url as [email protected]/path/to/repo.git@myTag work the way you want? That appears to create the .git/config file without the specific tags in the origin.fetch section -- it clones the repo and simply does git checkout myTag after cloning.

Apologies for not responding to your report sooner!

[nicksieger]

Also, I think we should create a test case for git_checkout that updates the tag and verifies that the repository state is changed.

It seems like the original intent for git_checkout is to clone a repository and keep it more-or-less fixed at the revision it originally retrieved. Using and/or changing @rev seems to work to update the repository, but if you don't specify a revision or branch or tag the default repository doesn't pull in changes, which seems to go against what people would expect.