[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: Local tag killer
From:       Jeff King <peff () peff ! net>
Date:       2013-09-30 23:18:03
Message-ID: 20130930231803.GA23218 () sigill ! intra ! peff ! net
[Download RAW message or body]

On Mon, Sep 30, 2013 at 06:44:09PM -0400, Nicolas Pitre wrote:

> > 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.
> 
> At least for typical Linux kernel workflows what I said above is true.

I could image if you are fetching from a bunch of coworkers that several
people might reuse a common name like "start" or "tmp" for different
purposes.

But I think the behavior you've described handles that quite naturally.
If there is one "start", or if they all match, it is unambiguous. If
there are multiple matches, git says "which one did you mean?" and you
can say "bob/start" or "alice/start" to disambiguate. Anything else
would be a guess.

If _you_ have a refs/tags/start, then I think that should unambiguously
take precedence over that of your coworkers. That way your coworkers
cannot pollute the lookup of items in your own namespace.

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