On 13-09-30 06:44 PM, Nicolas Pitre wrote:
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.
--
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