All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Branchaud <marcnarc@xiplink.com>
To: Nicolas Pitre <nico@fluxnic.net>
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 23:04:22 -0400	[thread overview]
Message-ID: <524A3BB6.9060808@xiplink.com> (raw)
In-Reply-To: <alpine.LFD.2.03.1309301839080.6331@syhkavp.arg>

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.

  parent reply	other threads:[~2013-10-01  3:04 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
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 [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=524A3BB6.9060808@xiplink.com \
    --to=marcnarc@xiplink.com \
    --cc=cmn@elego.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johan@herland.net \
    --cc=mhagger@alum.mit.edu \
    --cc=mschub@elegosoft.com \
    --cc=nico@fluxnic.net \
    --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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.