Re: Local tag killer
- From
Marc Branchaud <marcnarc@xiplink.com>
- Date
- Oct 1, 2013, 03:04 UTC
- Message-ID
- <524A3BB6.9060808@xiplink.com>
- In-Reply-To
- <alpine.LFD.2.03.1309301839080.6331@syhkavp.arg>
On 13-09-30 06:44 PM, Nicolas Pitre wrote:
Show 19 quoted lines
> On Mon, 30 Sep 2013, Marc Branchaud wrote: > >> On 13-09-30 04:08 PM, Nicolas Pitre wrote: >>> Again, in the cases where there is actually a SHA1 conflict between all >>> possible tags that match a tag short-end then listing them and asking the >>> user to be more explicit is the right thing to do. But that should be a >>> very rare case in practice, and designing for making this case easy is >>> the wrong approach. >>> >>> Instead, the common case of multiple remotes with duplicated tag names >>> referring to the same thing _and/or_ multiple remotes with distinct tags >>> names is what should be made easy to use with no extra steps. >> >> Again, I don't think that's the common case. I think it's just as likely for >> there to be multiple remotes with duplicate tag names that refer to different >> objects. > > Why do you say so? I'm curious to know what kind of work flow would do > that in practice.
The use case I have in mind is where a project makes use of other projects, for example an application that uses some libraries. The application's repository could contain the full histories of the libraries, each subtree-merged into a different directory.
So maybe that's not so common these days, but the current flat tag namespace makes it pretty much impractical.
M.