Re: [1.8.0] Provide proper remote ref namespaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jakub Narebski <jnareb@xxxxxxxxx> writes:

> Please consider this use case:
>
> Let's assume that current maintainer steps aside for a bit, and new interim
> temporary maintainer takes mantle.  One would add new remote _temporarily_,
> but one would want for tags that temporary maintainer created to be as good
> as tags from 'origin' remote... and not be deleted when you remove temp
> remote and its remote-tracking branches.

Why don't you want to delete them?

When the "interim" maintainer gives the baton back to the authoritative
maintainer, the tags that are blessed between these two maintainers will
surely be propagated [*1*] to the authoritative repository and you will
have them at refs/tags or refs/remotes/origin/tags in your repository.

And at that point, if you do not want to have refs/remotes/interim/heads/
branches, you surely do not mind cleaning refs/remotes/interim/tags/
hierarchy as well, no?

Having said all that, if we assume *1* above, then we wouldn't have needed
separate tag namespace in the first place.

Further, think about the case where the "interim" maintainer ends up
becoming the authoritative maintainer, which is the same thing as not
assuming *1* above.  You would want to consolidate refs/remotes/origin/tags
and refs/remotes/interim/tags, and we do not expect any collisions when we do
so.

Which suggests that tags namespace is really special in that it does want
to be globally unique and agreed namespace, unlike branch namespace.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]