On 13-09-30 11:28 PM, Nicolas Pitre wrote:
But with my proposal, you'd get a message saying that the tag "baz" is
ambigous, and that you'd have to use either "libfoo/baz" or
"libbar/baz".
Yes, and that's good. I agree with your proposal. Sorry if that wasn't
clear.
M.
--
On Mon, 30 Sep 2013, Marc Branchaud wrote:
> 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 ma
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 exp
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 wha
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.
On 13-09-30 04:08 PM, Nicolas Pitre wrote:
> On Mon, 30 Sep 2013, Marc Branchaud wrote:
>
>> On 13-09-30 11:52 AM, Nicolas Pitre wrote:
>>> Consider that I have in my Linux kernel tree:
>>>
>>> - a remote branch corresponding to Linus' master tree
>>>
>>> - multiple remote branches corresponding t
On Mon, 30 Sep 2013, Marc Branchaud wrote:
> On 13-09-30 11:52 AM, Nicolas Pitre wrote:
> > 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 fo
On 13-09-30 11:52 AM, Nicolas Pitre wrote:
> 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 war
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
> s
On 13-09-29 12:29 AM, Michael Haggerty wrote:
> On 09/28/2013 11:42 PM, Johan Herland wrote:
>> On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty
>> wrote:
>> [...]
>>> * How would somebody (e.g., an interim maintainer) suck down tags from
>>> a project into his own refs/tags/* namespace? (Wou
On Sun, Sep 29, 2013 at 6:29 AM, Michael Haggerty wrote:
> I wonder whether remotes.group could sensibly be used to group remotes
> into logical groups for value lookups:
>
> [remotes]
> gitk = gitk-origin
> gitk = second-gitk-repo
>
> Then DWIM could be taught to seek
On 09/28/2013 11:42 PM, Johan Herland wrote:
> On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty
> wrote:
>> [...]
>> Nicolas made the two best arguments for the necessity of
>> separate tag namespaces per remote in *some* form:
>> [...]
>
> I'd also like to mention my initial motivation for the
On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty wrote:
> I just reviewed that old thread to determine its relevance to the
> present discussion. For the benefit of the other readers, here is a
> summary of the main points that I got out of it.
I want to thank you immensely for the summary belo
On 09/26/2013 12:54 AM, Nicolas Pitre wrote:
> On Tue, 24 Sep 2013, Jeff King wrote:
>> I think most of this problem is the way that we fetch tags straight into
>> the refs/tags hierarchy. You would not do:
>>
>> [remote "origin"]
>> fetch = +refs/heads/*:refs/heads/*
>> prune = true
>>
>> un
On Tue, 24 Sep 2013, Jeff King wrote:
> On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote:
>
> > I think it would be preferable if "--prune" would *not* affect tags, and
> > if there were an extra option like "--prune-tags" that would have to be
> > used explicitly to cause tags to
On Tue, Sep 24, 2013 at 09:22:32AM -0400, Marc Branchaud wrote:
> >If we instead moved to a default fetch refspec more like:
> >
> > [remote "origin"]
> > fetch = +refs/*:refs/remotes/origin/refs/*
>
> I'm all for such a change.
>
> You no doubt recall the lengthy discussion about remote ref
On 13-09-24 03:51 AM, Jeff King wrote:
On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote:
I think it would be preferable if "--prune" would *not* affect tags, and
if there were an extra option like "--prune-tags" that would have to be
used explicitly to cause tags to be pruned.
On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote:
> I think it would be preferable if "--prune" would *not* affect tags, and
> if there were an extra option like "--prune-tags" that would have to be
> used explicitly to cause tags to be pruned. Would somebody object to
> such a ch
On Sat, Sep 21, 2013 at 2:42 AM, Michael Haggerty wrote:
> On 09/21/2013 12:51 AM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> I also agree that the documentation is misstated; "remote-tracking branch"
>>> may have been a convenient and well understood phrase for whoever wrote
>>> that
On 09/21/2013 12:51 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> I also agree that the documentation is misstated; "remote-tracking branch"
>> may have been a convenient and well understood phrase for whoever wrote
>> that part, but the --prune is designed to cull extra refs in the
>>
Junio C Hamano writes:
> I also agree that the documentation is misstated; "remote-tracking branch"
> may have been a convenient and well understood phrase for whoever wrote
> that part, but the --prune is designed to cull extra refs in the
> hierarchies into
> which refs would be fetched if coun
> When looking into this, I found a test in t5510 that appears to want to
> verify this very behavior:
>
>> test_expect_success 'fetch --prune --tags does not delete the
>> remote-tracking branches' '
The title tells me that it wants to make sure when pruning tags it does
not touch remote-trackin
A colleague of mine discovered, the hard way, that
git fetch --tags --prune $REMOTE
deletes all local tags that are not present on that particular remote.
To me this seems a dangerous and poorly-documented interaction of
features and arguably a bug.
Granted, it might not be such a good idea
23 matches
Mail list logo
