From: Johan Herland <johan@herland.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jakub Narebski <jnareb@gmail.com>,
Jeff King <peff@peff.net>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
Dmitry Potapov <dpotapov@gmail.com>,
Sverre Rabbelier <srabbelier@gmail.com>,
Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
Nicolas Pitre <nico@fluxnic.net>
Subject: Re: Re* [1.8.0] Provide proper remote ref namespaces
Date: Tue, 15 Feb 2011 16:06:20 +0100 [thread overview]
Message-ID: <201102151606.21040.johan@herland.net> (raw)
In-Reply-To: <7vfwrqtrsk.fsf_-_@alter.siamese.dyndns.org>
On Monday 14 February 2011, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > So if nobody disagree, I would have no problem with dropping the
> > leading "~" from the refspec, thus disabling auto-following
> > (tracking all tags explicitly instead).
>
> I am not sure what you mean by this. I think we agree that it would
> be Ok if you cannot add "~" in front to cause automatic following
> when tracking tags in separate namespaces using
> "refs/tags/*:refs/remotes/origin/tags/*".
>
> But are you saying:
>
> (1) There is no other change than that; or
>
> (2) Even when not using such a refspec i.e. using the traditional
> "tags live in a single global namespace", automatic following feature
> will be disabled;
>
> I would be moderately unhappy if the latter.
No, I'm saying the former.
For the foreseeable future (i.e. long after v1.8.0 is out) we will still
have to understand and support the traditional "tags are implicitly
auto-followed" and "tags live in a single global namespace" concepts
(aka. (a) below). For new-style remotes I propose that all refspecs be
explicit, and that auto-follow is disabled (aka. (b) below).
But if you try to specify a new-style remote with all tags in a single
global namespace, you will NOT get tag autofollowing (aka. (c) below)
(a): The current default config, also supported for the foreseeable
future (tag refspec is implicit, auto-following is enabled):
[remote "origin"]
url = ...
fetch = +refs/heads/*:refs/remotes/origin/*
(b): The proposed default config, using separate per-remote namespaces
for tags (tag refspec is explicit, auto-following is disabled):
[remote "origin"]
url = ...
fetch = +refs/heads/*:refs/remotes/origin/heads/*
fetch = +refs/tags/*:refs/remotes/origin/tags/*
(c): A customized version of the proposed config, using a single global
namespace for tags (tag refspec is explicit, auto-following is
disabled):
[remote "origin"]
url = ...
fetch = +refs/heads/*:refs/remotes/origin/(heads/)*
fetch = refs/tags/*:refs/tags/*
(Note that if we cannot reliably detect the difference between old-style
(implicit) and new-style (explicit) remotes, we will likely have to add
a boolean flag, e.g. "remote.origin.implicitTagFollowing".)
> > ... However, what I've seen at $dayjob is
> > that more inexperienced users will often push right after
> > committing, and at that time they're still very much in the
> > "working-on-one-branch" state of mind (as opposed to the
> > "administering-multiple-branches" state of mind),...
>
> Then "current" mode is a good setting for them, I would presume.
Arguably in some workflows, 'tracking' may be a more suitable default
(i.e. safer for newbies) than 'current', but in practice this shouldn't
matter much (local branch names usually correspond to remote branch
names). Also, 'tracking' is more complicated when the branch originates
locally, and must be created on the server ("git push -u origin
<branch>" vs. "git push"). So I agree that 'current' is the best
default.
...Johan
Offtopic PS: Given that we're leaning towards using 'tracking' to
describe the relationship between remote-tracking branches
(refs/remotes/*) and remote branches, and 'upstream' to describe the
relationship between a local branch and the remote branch it
follows/merges (on 'git pull'), wouldn't
push.default == "upstream"
be more descriptive than
push.default == "tracking"
?
--
Johan Herland, <johan@herland.net>
www.herland.net
next prev parent reply other threads:[~2011-02-15 15:09 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 10:44 [1.8.0] Remote tag namespace Nguyen Thai Ngoc Duy
2011-02-01 14:10 ` Leo Razoumov
2011-02-01 15:07 ` Marc Branchaud
2011-02-01 15:35 ` Nguyen Thai Ngoc Duy
2011-02-02 19:38 ` Marc Branchaud
2011-02-01 18:14 ` Jeff King
2011-02-01 23:14 ` Sverre Rabbelier
2011-02-02 2:21 ` [1.8.0] Provide proper remote ref namespaces Johan Herland
2011-02-02 13:27 ` Santi Béjar
2011-02-02 15:51 ` Johan Herland
2011-02-02 16:19 ` Santi Béjar
2011-02-03 5:33 ` Nguyen Thai Ngoc Duy
2011-02-03 8:46 ` Johan Herland
2011-02-03 11:35 ` Nguyen Thai Ngoc Duy
2011-02-03 13:10 ` Johan Herland
2011-02-03 14:10 ` Santi Béjar
2011-02-03 15:48 ` Nguyen Thai Ngoc Duy
2011-02-04 22:39 ` Junio C Hamano
2011-02-05 1:18 ` Johan Herland
2011-02-05 18:00 ` Kevin P. Fleming
2011-02-05 21:40 ` Dmitry Potapov
2011-02-06 0:04 ` Johan Herland
2011-02-06 12:03 ` Dmitry Potapov
2011-02-06 14:09 ` Nicolas Pitre
2011-02-06 15:17 ` Dmitry Potapov
2011-02-06 16:11 ` Johan Herland
2011-02-06 17:28 ` Dmitry Potapov
2011-02-06 22:12 ` Johan Herland
2011-02-07 0:07 ` Dmitry Potapov
2011-02-07 19:05 ` Bernhard R. Link
2011-02-08 1:20 ` Dmitry Potapov
[not found] ` <201102070429.05033.johan@herland.net>
2011-02-07 3:47 ` Nicolas Pitre
2011-02-08 1:06 ` Dmitry Potapov
2011-02-08 8:15 ` Johan Herland
2011-02-08 19:11 ` Enrico Weigelt
2011-02-08 23:13 ` Junio C Hamano
2011-02-09 1:24 ` Johan Herland
2011-02-06 20:28 ` Matthieu Moy
2011-02-06 23:22 ` Johan Herland
2011-02-06 23:51 ` Matthieu Moy
2011-02-07 3:51 ` Johan Herland
2011-02-07 5:11 ` Jeff King
2011-02-07 8:58 ` Johan Herland
2011-02-07 9:01 ` Sverre Rabbelier
2011-02-07 10:06 ` Johan Herland
2011-02-07 10:22 ` Nguyen Thai Ngoc Duy
2011-02-07 20:19 ` Jeff King
2011-02-08 0:59 ` Johan Herland
2011-02-11 15:13 ` Jakub Narebski
2011-02-13 23:36 ` Johan Herland
2011-02-14 7:35 ` Junio C Hamano
2011-02-14 9:18 ` Johan Herland
2011-02-14 9:59 ` Jakub Narebski
2011-02-14 17:30 ` Junio C Hamano
2011-02-14 18:06 ` Re* " Junio C Hamano
2011-02-14 18:53 ` Jay Soffian
2011-02-14 19:44 ` Sverre Rabbelier
2011-02-14 19:50 ` Jay Soffian
2011-02-14 21:21 ` [1.8.0 RFC] push: start warning upcoming default change for push.default Jonathan Nieder
2011-02-14 21:41 ` Jay Soffian
2011-02-14 21:55 ` Jonathan Nieder
2011-02-14 21:57 ` Re* [1.8.0] Provide proper remote ref namespaces Matthieu Moy
2011-02-14 22:35 ` Jeff King
2011-02-14 22:38 ` Sverre Rabbelier
2011-02-14 23:36 ` [1.8.0 RFC] push: start warning upcoming default change for push.default Jonathan Nieder
2011-02-14 23:45 ` Re* [1.8.0] Provide proper remote ref namespaces Junio C Hamano
2011-02-14 23:05 ` Junio C Hamano
2011-02-15 15:06 ` Johan Herland [this message]
2011-02-15 18:06 ` Junio C Hamano
2011-02-16 0:54 ` [PATCH] push.default: Rename 'tracking' to 'upstream' Johan Herland
2011-02-16 6:35 ` Junio C Hamano
2011-02-16 8:55 ` Matthieu Moy
2011-02-16 9:42 ` Martin von Zweigbergk
2011-02-16 10:08 ` Jakub Narebski
2011-02-16 10:26 ` Matthieu Moy
2011-02-16 10:27 ` Sverre Rabbelier
2011-02-16 17:56 ` Junio C Hamano
2011-02-16 18:08 ` Sverre Rabbelier
2011-02-16 18:37 ` Junio C Hamano
2011-02-18 0:51 ` Martin von Zweigbergk
2011-02-18 0:57 ` Martin von Zweigbergk
2011-02-16 10:54 ` Bernhard R. Link
2011-02-14 9:40 ` [1.8.0] Provide proper remote ref namespaces Jakub Narebski
2011-02-14 15:45 ` Marc Branchaud
2011-02-14 19:35 ` Nicolas Pitre
2011-02-14 18:30 ` Junio C Hamano
2011-02-14 19:06 ` Nicolas Pitre
2011-02-14 19:46 ` Sverre Rabbelier
2011-02-07 6:54 ` Matthieu Moy
2011-02-07 0:14 ` Dmitry Potapov
2011-02-05 18:39 ` Nicolas Pitre
2011-02-05 19:37 ` Jeff King
2011-02-05 19:55 ` Nicolas Pitre
2011-02-05 23:39 ` Johan Herland
2011-02-06 20:04 ` Junio C Hamano
2011-02-07 16:10 ` Marc Branchaud
2011-02-07 19:40 ` Junio C Hamano
2011-02-07 20:37 ` Nicolas Pitre
2011-02-07 5:18 ` Jeff King
2011-02-07 14:53 ` Nicolas Pitre
2011-02-07 20:25 ` Jeff King
2011-02-07 20:51 ` Nicolas Pitre
2011-02-07 20:56 ` Jeff King
2011-02-01 23:15 ` [1.8.0] Remote tag namespace Johan Herland
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=201102151606.21040.johan@herland.net \
--to=johan@herland.net \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=dpotapov@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=nico@fluxnic.net \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=srabbelier@gmail.com \
/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).