Re: Fetching tags overwrites existing tags

[Jacob Keller <jacob.keller@gmail.com>]

On Tue, Apr 24, 2018 at 12:57 PM, Wink Saville <wink@saville.com> wrote:
> If have a repository with a tag "v1.0.0" and I add a remote repository
> which also has a tag "v1.0.0" tag is overwritten.
>
> Google found [1] from 2011 and option 3 is what I'd like to see. Has it been
> implemented and I just don't see it?
>
> [1]: https://groups.google.com/forum/#!topic/git-version-control/0l_rJFyTE60
>
>
> Here is an example demonstrating what I see:
>
> $ echo abc > abc.txt
> $ git init .
> Initialized empty Git repository in
> /home/wink/prgs/git/investigate-fetch-tags/.git/
> $ git add *
> $ git commit -m "Initial commit"
> [master (root-commit) 1116fdc] Initial commit
>  1 file changed, 1 insertion(+)
>  create mode 100644 abc.txt
> $ git tag v1.0.0
> $ git remote add gbenchmark git@github.com:google/benchmark
> $ git log --graph --format="%h %s %d"
> * 1116fdc Initial commit  (HEAD -> master, tag: v1.0.0)
> $ git fetch --tags gbenchmark
> warning: no common commits
> remote: Counting objects: 4400, done.
> remote: Compressing objects: 100% (15/15), done.
> remote: Total 4400 (delta 5), reused 5 (delta 3), pack-reused 4382
> Receiving objects: 100% (4400/4400), 1.33 MiB | 2.81 MiB/s, done.
> Resolving deltas: 100% (2863/2863), done.
> From github.com:google/benchmark
>  * [new branch]      clangtidy       -> gbenchmark/clangtidy
>  * [new branch]      iter_report     -> gbenchmark/iter_report
>  * [new branch]      master          -> gbenchmark/master
>  * [new branch]      releasing       -> gbenchmark/releasing
>  * [new branch]      reportercleanup -> gbenchmark/reportercleanup
>  * [new branch]      rmheaders       -> gbenchmark/rmheaders
>  * [new branch]      v2              -> gbenchmark/v2
>  * [new tag]         v0.0.9          -> v0.0.9
>  * [new tag]         v0.1.0          -> v0.1.0
>  t [tag update]      v1.0.0          -> v1.0.0
>  * [new tag]         v1.1.0          -> v1.1.0
>  * [new tag]         v1.2.0          -> v1.2.0
>  * [new tag]         v1.3.0          -> v1.3.0
>  * [new tag]         v1.4.0          -> v1.4.0
> $ git log --graph --format="%h %s %d"
> * 1116fdc Initial commit  (HEAD -> master)
>
> As you can see the tag on 1116fdc is gone, v1.0.0 tag has been updated
> and now its pointing to the tag in gbenchmark:
>
> $ git log -5 --graph --format="%h %s %d" v1.0.0
> *   cd525ae Merge pull request #171 from eliben/update-doc-userealtime
>  (tag: v1.0.0)
> |\
> | * c7ab1b9 Update README to mention UseRealTime for wallclock time
> measurements.
> |/
> * f662e8b Rename OS_MACOSX macro to new name BENCHMARK_OS_MACOSX. Fix #169
> *   0a1f484 Merge pull request #166 from disconnect3d/master
> |\
> | * d2917bc Fixes #165: CustomArguments ret type in README
> |/
>
> Ideally I would have liked the tags fetched from gbenchmark to have a prefix
> of gbenchmark/, like the branches have, maybe something like:
>

That would require a complete redesign of how we handle remotes. I've
proposed ideas in the past but never had time and they didn't gain
much traction.

It's a known limitation that the tags namespace can only hold a single
tag name (even if remotes differ in what that tag is). I *thought*
that the tags should not be updated after you fetch it once, but it
seems this is not the behavior we get now?

My basic idea was to fetch *all* remote refs into a
refs/<remotes-bikeshed>/<remote-name>/* such that *every* ref in a
remote can be determined by something like
"refs/tracking/origin/tags/name" instead of
"refs/remotes/origin/name", and then tags would have to be updated to
check for tags in each remote as well as locally. Additionally, you
could update the tool to warn when two remotes have the same tag at
different refs, and allow disambiguation.

Ideally, "origin/branch" should still DWIM, same for "tag" should work
unless there are conflicts.

Unfortunately, it's a pretty big change in how remotes are handled,
and I never had time to actually work towards a POC or implementation.
Mostly, we ended up on bikeshedding what the name should be now that
we can't use "refs/remotes" due to backwards compatibility. I don't
really like "tracking" as a name, but it was the best I could come up
with.

(Note, the impetus for this proposal was actually to allow easy
sharing of notes and other specialized refs).

Thanks,
Jake

> $ git fetch --tags gbenchmark
> ...
>  * [new branch]      v2              -> gbenchmark/v2
>  * [new tag]         v0.0.9          -> gbenchmark/v0.0.9
>  * [new tag]         v0.1.0          -> gbenchmark/v0.1.0
>  * [new tag]         v1.0.0          -> gbenchmark/v1.0.0
>  * [new tag]         v1.1.0          -> gbenchmark/v1.1.0
>  * [new tag]         v1.2.0          -> gbenchmark/v1.2.0
>  * [new tag]         v1.3.0          -> gbenchmark/v1.3.0
>  * [new tag]         v1.4.0          -> gbenchmark/v1.4.0
>
>
> -- Wink