Re: Re* [1.8.0] Provide proper remote ref namespaces

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Re* [1.8.0] Provide proper remote ref namespaces

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:50:34

Johan Herland [off-list ref] writes:
On Monday 14 February 2011, Junio C Hamano wrote:
...
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)
Ok.
(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".)
Ok.
quoted
quoted
... 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).
Of course you are right.  The "this pulls from there, and pushes back
to the same place" model was what I had in mind when I wrote the patch; 
I just was confused between the "tracking" vs "current" labels.
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"
"Local Branch" and "Remote Tracking Branch", both of which physically
reside on the local end of the communication and are tied by their
"merge/rebase" relationship, are much more distinct than "Remote Branch"
and "Remote Tracking Branch" that are tied by their "fetch" relationship.
A remote tracking branch is a mere (time-lagged) mirror of the remote
branch it tracks, and mental distance between them is much smaller than
that of between a local branch and its @{upstream} that is a remote
tracking branch.  Conceptually the _true_ upstream of a local branch is
the remote branch from which its @{upstream} remote tracking branch copies
from.

So in that sense, I agree "pushing my change to the upstream" would match
the mental model of an end user somewhat better than "pushing my change
back to what I track".

Perhaps leave "tracking" as a deprecated synonym and add "upstream" as the
official name of the mode?

[PATCH] push.default: Rename 'tracking' to 'upstream'

From: Johan Herland <hidden>
Date: 2016-06-15 22:50:34

Users are sometimes confused with two different types of "tracking" behavior
in Git: "remote-tracking" branches (e.g. refs/remotes/*/*) versus the
merge/rebase relationship between a local branch and its @{upstream}
(controlled by branch.foo.remote and branch.foo.merge config settings).

When the push.default is set to 'tracking', it specifies that a branch should
be pushed to its @{upstream} branch. In other words, setting push.default to
'tracking' applies only to the latter of the above two types of "tracking"
behavior.

In order to make this more understandable to the user, we rename the
push.default == 'tracking' option to push.default == 'upstream'.

push.default == 'tracking' is left as a deprecated synonym for 'upstream'.

Signed-off-by: Johan Herland <redacted>
---

On Tuesday 15 February 2011, Junio C Hamano wrote:
Perhaps leave "tracking" as a deprecated synonym and add "upstream" as
the official name of the mode?
This patch does just that.

I took the liberty of renaming the setup_push_tracking() function as
well, and rephrasing its error messages. Although this may be
considered code churn, I think it's worth keeping the function naming
closer to the phrasing in the documentation.


Have fun! :)

...Johan


 Documentation/config.txt |    3 ++-
 builtin/push.c           |   10 +++++-----
 cache.h                  |    2 +-
 config.c                 |    6 ++++--
 4 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c5e1835..c995a1a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1591,7 +1591,8 @@ push.default::
 * `matching` - push all matching branches.
   All branches having the same name in both ends are considered to be
   matching. This is the default.
-* `tracking` - push the current branch to its upstream branch.
+* `upstream` - push the current branch to its upstream branch.
+* `tracking` - deprecated synonym for `upstream`.
 * `current` - push the current branch to a branch of the same name.
 
 rebase.stat::
diff --git a/builtin/push.c b/builtin/push.c
index e655eb7..31da418 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -64,17 +64,17 @@ static void set_refspecs(const char **refs, int nr)
 	}
 }
 
-static void setup_push_tracking(void)
+static void setup_push_upstream(void)
 {
 	struct strbuf refspec = STRBUF_INIT;
 	struct branch *branch = branch_get(NULL);
 	if (!branch)
 		die("You are not currently on a branch.");
 	if (!branch->merge_nr || !branch->merge)
-		die("The current branch %s is not tracking anything.",
+		die("The current branch %s has no upstream branch.",
 		    branch->name);
 	if (branch->merge_nr != 1)
-		die("The current branch %s is tracking multiple branches, "
+		die("The current branch %s has multiple upstream branches, "
 		    "refusing to push.", branch->name);
 	strbuf_addf(&refspec, "%s:%s", branch->name, branch->merge[0]->src);
 	add_refspec(refspec.buf);
@@ -88,8 +88,8 @@ static void setup_default_push_refspecs(void)
 		add_refspec(":");
 		break;
 
-	case PUSH_DEFAULT_TRACKING:
-		setup_push_tracking();
+	case PUSH_DEFAULT_UPSTREAM:
+		setup_push_upstream();
 		break;
 
 	case PUSH_DEFAULT_CURRENT:
diff --git a/cache.h b/cache.h
index d83d68c..7acf120 100644
--- a/cache.h
+++ b/cache.h
@@ -608,7 +608,7 @@ enum rebase_setup_type {
 enum push_default_type {
 	PUSH_DEFAULT_NOTHING = 0,
 	PUSH_DEFAULT_MATCHING,
-	PUSH_DEFAULT_TRACKING,
+	PUSH_DEFAULT_UPSTREAM,
 	PUSH_DEFAULT_CURRENT
 };
 
diff --git a/config.c b/config.c
index 625e051..9184900 100644
--- a/config.c
+++ b/config.c
@@ -737,8 +737,10 @@ static int git_default_push_config(const char *var, const char *value)
 			push_default = PUSH_DEFAULT_NOTHING;
 		else if (!strcmp(value, "matching"))
 			push_default = PUSH_DEFAULT_MATCHING;
-		else if (!strcmp(value, "tracking"))
-			push_default = PUSH_DEFAULT_TRACKING;
+		else if (!strcmp(value, "upstream"))
+			push_default = PUSH_DEFAULT_UPSTREAM;
+		else if (!strcmp(value, "tracking")) /* deprecated */
+			push_default = PUSH_DEFAULT_UPSTREAM;
 		else if (!strcmp(value, "current"))
 			push_default = PUSH_DEFAULT_CURRENT;
 		else {
-- 
1.7.4
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help