2

After looking at Git tags and seeing how they are propagated and how many workarounds there are to pruning them, I concluded that the best fix would be to change the structure of refs/remotes/origin/. So, why are refs under refs/remotes/origin/ assumed to be branches? It would have been easy to replicate the top-level structure under the remote ref too:

refs/remotes/origin/heads/  <-- remote tracking branches
refs/remotes/origin/tags/   <-- remote tracking tags
refs/remotes/origin/notes/  <-- remote tracking notes

But all tools that work with Git assume that refs under refs/remotes/origin/ are branches.

Is there an actual reason this is the way things are or is it merely an accident?

Edit 1:

After looking into this a little more I found that git log --decorate will correctly show annotated tags under the refs/remotes/origin/tags/* but lightweight tags show up as branches.

Config file:

[remote "origin"]
    url = ssh://git@github.com/test/example.git
    fetch = +refs/heads/*:refs/remotes/origin/heads/*
    fetch = +refs/tags/*:refs/remotes/origin/tags/*

Lightweight tag:

commit e447ca1e2f3c765072c6bd783981619da3d6a090 (tag: v0.2, origin/tags/v0.2)
Author: Joanna Blogs <joanna@blogs.com>
Date:   Thu Aug 18 14:38:48 2016 -0500

    Testing out a light weight tag

Annotated tag:

commit 334d587e8f9bad1756665384056760c0cb798f32 (tag: v0.1, tag: origin/tags/v0.1)
Author: Joe Blogs <joe@blogs.com>
Date:   Fri Jul 1 09:24:25 2016 -0500

    Testing an annotated tag

However, as expected, the git tag -l command doesn't show them at all.

nonsensickle
  • 4,438
  • 2
  • 34
  • 61

1 Answers1

4

[Edited substantially less than a day after being answered: previous answer was based on a different, mis-remembered issue.]

Tags are intended to be global / universal. That is, there is no such thing, in Git, as a "remote tag".

There is no technical reason Git can't have remote tags. In fact, it could have both remote-tracking-tags (always force-updated) and global tags (not-force-updated). Here's one way to implement them manually:

[remote "R"]
    url = ...
    fetch = +refs/heads/*:refs/remotes/R/*
    fetch = +refs/tags/*:refs/rtags/R/*
    fetch = refs/tags/*:refs/tags/*

Now when you git fetch R, if you already have a tag blue and they have an unrelated blue, you'd get refs/rtags/R/blue but would not update your own refs/tags/blue.

(This is not all that convenient since you have to spell out rtags/R/blue, but in the case of a collision you would have to spell it out anyway to avoid ambiguity.)

If you're asking: "remote tags instead of global tags seem like a good idea, why doesn't Git do them?", my answer would be "history, inertia, stubbornness, etc.", but of course you would really have to ask the Git maintainers directly. (It does seem impolite to remove global tags. :-) )

If you're asking "remote tags in addition to global tags seems like a good idea, why doesn't Git do them?" my answer would be "I don't know". It's true that I had to put this under refs/rtags/R rather than refs/remotes/R/tags/ since there's no room in refs/remotes/R for anything other than branches. If the Git folks were to adopt this in full generality, perhaps your own implied suggestion, of simply copying refs/* to refs/remotes-new/*, then treating them as tags, notes, etc., automatically, would be best.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Your answer confirms my assumptions but brings up some new information as well. Would you mind elaborating on what you mean by *"reference mapping code currently doesn't like the idea that one remote reference might map to two (or more) local references"*? Perhaps provide a link I could follow? – nonsensickle Sep 09 '16 at 08:46
  • Actually, it turns out I was just wrong about this: it's not a problem to map `refs/tags/*` to both `refs/tags/*` and `refs/remotes/rtags/*`. The problem case is when two different remote refs map to a single local remote-tracking ref. (So doing "remote tags" *with* the global-tag behavior as well, is possible today.) See http://stackoverflow.com/q/21998181/1256452 for the other issue. – torek Sep 09 '16 at 09:36
  • I see what you mean but that's solvable with proper structuring or rearranging of the refs. Alternatively, the ref itself currently has 2 types which is either symbolic or normal. We could expand this to give refs a type, like "branch" or "tag"... – nonsensickle Sep 09 '16 at 10:57
  • I have an idea how this could be implemented in Git. I have recorded it [here](https://github.com/orao/git/issues/1) and will try and implement it. We'll see what the maintainers think. – nonsensickle Sep 09 '16 at 11:20