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.
--
To
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 mhag...@alum.mit.edu
wrote:
[...]
* How would somebody (e.g., an interim maintainer) suck down tags from
a project into his own refs/tags/*
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
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 warnings?
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 for linux-next
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 to Linux stable
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
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
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
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 match a tag
On Sun, Sep 29, 2013 at 6:29 AM, Michael Haggerty mhag...@alum.mit.edu 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
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
unless you wanted to
On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty mhag...@alum.mit.edu 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
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
namespaces
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 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 change?
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 09/21/2013 12:51 AM, Junio C Hamano wrote:
Junio C Hamano gitster-v...@pobox.com 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
On Sat, Sep 21, 2013 at 2:42 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 09/21/2013 12:51 AM, Junio C Hamano wrote:
Junio C Hamano gitster-v...@pobox.com writes:
I also agree that the documentation is misstated; remote-tracking branch
may have been a convenient and well understood
Junio C Hamano gitster-v...@pobox.com 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
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
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-tracking
22 matches
Mail list logo
