From: Nicolas Pitre <nico@fluxnic.net>
To: Marc Branchaud <mbranchaud@xiplink.com>
Cc: "Michael Haggerty" <mhagger@alum.mit.edu>,
"Johan Herland" <johan@herland.net>, "Jeff King" <peff@peff.net>,
"Junio C Hamano" <gitster@pobox.com>,
"Git mailing list" <git@vger.kernel.org>,
"Carlos Martín Nieto" <cmn@elego.de>,
"Michael Schubert" <mschub@elegosoft.com>
Subject: Re: Local tag killer
Date: Mon, 30 Sep 2013 11:52:47 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.2.03.1309301138200.6331@syhkavp.arg> (raw)
In-Reply-To: <52499797.9030100@xiplink.com>
On Mon, 30 Sep 2013, Marc Branchaud wrote:
> Why would there be ambiguity warnings? The fetch command shouldn't issue any
> warnings, since all the remotes' names get safely tucked away in distinct
> namespaces.
>
> Are we talking about DWIM warnings? Aside from git-describe I don't see why
> such warnings would be a problem. To DWIM-resolve a tag name look in
> refs/tags/* and refs/remotes/*/tags/* -- much like it's done for branches
> already. If a tag name has multiple matches then it's ambiguous. Git could
> be clever and check for matching SHA1 values, but why bother? It almost
> seems like a disservice to silently disambiguate such names. I would think a
> user would prefer to know about any possible ambiguities, rather than have
> some suddenly appear (and maybe also disappear).
Consider that I have in my Linux kernel tree:
- a remote branch corresponding to Linus' master tree
- multiple remote branches corresponding to Linux stable branches
- a remote for linux-next which is a repo constantly being rebased
Now all those repositories share the mainline tags from Linus' repo and
they add some more of they own which are not shared. So if they all
have a v3.11 tag that resolve to the same SHA1, then there is
effectively no ambiguity at all and git should not warn at all.
*However* if one of those v3.11 tags does not agree with the others
_then_ I want to be warned about it.
So having multiple matching tags that do resolve to the same SHA1 across
different remote repositories _is_ the norm and should work
transparently.
Nicolas
next prev parent reply other threads:[~2013-09-30 15:52 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 2:54 Local tag killer Michael Haggerty
2013-09-13 4:03 ` Junio C Hamano
2013-09-20 22:51 ` Junio C Hamano
2013-09-21 6:42 ` Michael Haggerty
2013-09-21 12:28 ` John Szakmeister
2013-09-24 7:51 ` Jeff King
2013-09-24 13:22 ` Marc Branchaud
2013-09-25 8:22 ` Jeff King
2013-09-25 22:54 ` Nicolas Pitre
2013-09-28 12:20 ` Michael Haggerty
2013-09-28 21:42 ` Johan Herland
2013-09-29 4:29 ` Michael Haggerty
2013-09-29 9:30 ` Johan Herland
2013-09-30 15:24 ` Marc Branchaud
2013-09-30 15:52 ` Nicolas Pitre [this message]
2013-09-30 19:16 ` Marc Branchaud
2013-09-30 20:08 ` Nicolas Pitre
2013-09-30 21:14 ` Marc Branchaud
2013-09-30 22:44 ` Nicolas Pitre
2013-09-30 23:18 ` Jeff King
2013-10-01 3:04 ` Marc Branchaud
2013-10-01 3:28 ` Nicolas Pitre
2013-10-01 12:45 ` Marc Branchaud
2013-10-23 15:50 ` [PATCH 00/15] Change semantics of "fetch --tags" Michael Haggerty
2013-10-23 15:50 ` [PATCH 01/15] t5510: use the correct tag name in test Michael Haggerty
2013-10-23 15:50 ` [PATCH 02/15] t5510: prepare test refs more straightforwardly Michael Haggerty
2013-10-23 18:36 ` Junio C Hamano
2013-10-24 6:49 ` Michael Haggerty
2013-10-24 19:50 ` Junio C Hamano
2013-10-23 15:50 ` [PATCH 03/15] t5510: check that "git fetch --prune --tags" does not prune branches Michael Haggerty
2013-10-23 15:50 ` [PATCH 04/15] api-remote.txt: correct section "struct refspect" Michael Haggerty
2013-10-23 18:43 ` Junio C Hamano
2013-10-24 7:06 ` Michael Haggerty
2013-10-23 15:50 ` [PATCH 05/15] get_ref_map(): rename local variables Michael Haggerty
2013-10-23 18:45 ` Junio C Hamano
2013-10-24 7:24 ` Michael Haggerty
2013-10-23 15:50 ` [PATCH 06/15] ref_remove_duplicates(): avoid redundant bisection Michael Haggerty
2013-10-23 15:50 ` [PATCH 07/15] ref_remove_duplicates(): simplify function Michael Haggerty
2013-10-23 15:50 ` [PATCH 08/15] ref_remove_duplicates(): improve documentation comment Michael Haggerty
2013-10-23 18:47 ` Junio C Hamano
2013-10-23 15:50 ` [PATCH 09/15] builtin/fetch.c: reorder function definitions Michael Haggerty
2013-10-23 15:50 ` [PATCH 10/15] fetch --tags: fetch tags *in addition to* other stuff Michael Haggerty
2013-10-24 20:51 ` Junio C Hamano
2013-10-25 15:08 ` Michael Haggerty
2013-10-28 19:10 ` Junio C Hamano
2013-10-30 4:26 ` Michael Haggerty
2013-10-26 5:10 ` Michael Haggerty
2013-10-23 15:50 ` [PATCH 11/15] fetch --prune: prune only based on explicit refspecs Michael Haggerty
2013-10-24 21:11 ` Junio C Hamano
2013-10-26 6:49 ` Michael Haggerty
2013-10-28 15:08 ` Junio C Hamano
2013-10-23 15:50 ` [PATCH 12/15] query_refspecs(): move some constants out of the loop Michael Haggerty
2013-10-23 15:50 ` [PATCH 13/15] builtin/remote.c: reorder function definitions Michael Haggerty
2013-10-23 15:50 ` [PATCH 14/15] builtin/remote.c:update(): use struct argv_array Michael Haggerty
2013-10-23 15:50 ` [PATCH 15/15] fetch, remote: properly convey --no-prune options to subprocesses Michael Haggerty
2013-10-24 21:17 ` Junio C Hamano
2013-10-23 16:59 ` [PATCH 00/15] Change semantics of "fetch --tags" Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.03.1309301138200.6331@syhkavp.arg \
--to=nico@fluxnic.net \
--cc=cmn@elego.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johan@herland.net \
--cc=mbranchaud@xiplink.com \
--cc=mhagger@alum.mit.edu \
--cc=mschub@elegosoft.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).