[RFC/PATCH] git push usability improvements and default change

[RFC/PATCH] git push usability improvements and default change

[Finn Arne Gangstad]

Usability improvements:

"-" is now an alias for the current remote (the remote of the current
branch or "origin" as a fallback). This works both for push, fetch,
pull, remote (and possibly some others), creating a lot of nice
shortcuts I think:
git remote prune - : prune the current remote
git push - HEAD : push the current branch to a branch of the same name
git fetch - next : fetch the next branch from the current remote

git push has learned two new command line options --matching and
--current, which override any configuration.  'matching' pushes all
branches that already exist at the remote, while 'current' pushes the
current branch to whatever it is tracking

I chose this behaviour for 'current', since it is the one that I find
most useful, and there seems to be no good way of expressing it from
the command line.  Pushing a branch to an identically named branch on
a remote can now easily be done by "git push - HEAD".

Also added a new configuration option push.default, which can have values
"nothing", "matching" and "current". This variable will only be used if
you have not specificed any refspecs at all, no command line options imply
any refspecs, and the current branch has no push configuration.

This is implemented in 1-3


git push default change:

git push will by default push "nothing" instead of "matching".

This is implemented in 4-7. 4-5 are for immediate consumption, 6 is for
next major release (or later), and 7 is even later.

4 Adds a warning if you have not configured push.default
5 Changes the wording to say that the default will change. 4 and 5 can
  be applied immediately.
6 changes the deault to "nothing", but keeps the warning.
7 removes the warning entirely

Finn Arne Gangstad (7):
      remote: Make "-" an alias for the current remote
      New config option push.default
      git push: New options --matching and --current
      git push: Display warning on unconfigured default push
      git push: Document that "nothing" is the future push default
      git push: Change default for "git push" to nothing.
      git push: Remove warning for "git push" default change

 Documentation/RelNotes-1.6.3.txt |    7 +++
 Documentation/config.txt         |   18 ++++++++
 Documentation/git-push.txt       |   14 +++++--
 builtin-push.c                   |   84 +++++++++++++++++++++++++++++--------
 cache.h                          |    7 +++
 config.c                         |   23 ++++++++++
 environment.c                    |    1 +
 remote.c                         |    2 +-
 transport.h                      |    9 ++++
 9 files changed, 142 insertions(+), 23 deletions(-)

- Finn Arne

[PATCH 1/7] remote: Make "-" an alias for the current remote

[Finn Arne Gangstad]

This creates a handy alias "-" for the remote of the current branch
(or origin if no such remote exists), which can be used in both
push, pull, fetch and remote to make many tasks easier. E.g.:
git push - HEAD  : push the current branch
git remote prune - : prune the current remote
git fetch - next : get the next branch from the current remote

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 remote.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/remote.c b/remote.c
index d7079c6..3a6d002 100644
--- a/remote.c
+++ b/remote.c
@@ -645,7 +645,7 @@ struct remote *remote_get(const char *name)
 	struct remote *ret;
 
 	read_config();
-	if (!name)
+	if (!name || !strcmp(name, "-"))
 		name = default_remote_name;
 	ret = make_remote(name, 0);
 	if (valid_remote_nick(name)) {
-- 
1.6.2.105.g6ff1f.dirty

[PATCH 2/7] New config option push.default

[Finn Arne Gangstad]

This option takes effect when no refspec is given explicitly or implicitly
by any of the command line arguments to push, and no refspec is configured
for the current remote. The possible values are:
* nothing - do not push anything
* current - push the current branch to whatever it is tracking
* matching - push all branches that already exist remotely (same name)

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/config.txt |   18 ++++++++++++++++++
 cache.h                  |    8 ++++++++
 config.c                 |   23 +++++++++++++++++++++++
 environment.c            |    1 +
 4 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index f5152c5..50bc1d0 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1160,6 +1160,24 @@ pull.octopus::
 pull.twohead::
 	The default merge strategy to use when pulling a single branch.
 
+push.default::
+	Defines the action git push should take if no refspec is given
+	on the command line, no refspec is configured in the remote, and
+	no refspec is implied by any of the options given on the command
+	line.
+
+	The term `current remote` means the remote configured for the current
+	branch, or `origin` if no remote is configured. `origin` is also used
+	if you are not on any branch.
++
+* `nothing` do not push anything
+* `matching` push all matching branches to the current remote.
+  All branches having the same name in both ends are considered to be
+  matching. This is the default value.
+* `current` push the current branch to the branch it is tracking on
+  the remote
+
+
 receive.fsckObjects::
 	If it is set to true, git-receive-pack will check all received
 	objects. It will abort in the case of a malformed object or a
diff --git a/cache.h b/cache.h
index 189151d..3a6acb8 100644
--- a/cache.h
+++ b/cache.h
@@ -541,8 +541,16 @@ enum rebase_setup_type {
 	AUTOREBASE_ALWAYS,
 };
 
+enum push_default_type {
+	PUSH_DEFAULT_UNSPECIFIED = -1,
+	PUSH_DEFAULT_NOTHING = 0,
+	PUSH_DEFAULT_MATCHING,
+	PUSH_DEFAULT_CURRENT,
+};
+
 extern enum branch_track git_branch_track;
 extern enum rebase_setup_type autorebase;
+extern enum push_default_type push_default;
 
 #define GIT_REPO_VERSION 0
 extern int repository_format_version;
diff --git a/config.c b/config.c
index 0c8c76f..12d5a2b 100644
--- a/config.c
+++ b/config.c
@@ -565,6 +565,26 @@ static int git_default_branch_config(const char *var, const char *value)
 	return 0;
 }
 
+static int git_default_push_config(const char *var, const char *value)
+{
+	if (!strcmp(var, "push.default")) {
+		if (!value)
+			return config_error_nonbool(var);
+		else if (!strcmp(value, "nothing"))
+			push_default = PUSH_DEFAULT_NOTHING;
+		else if (!strcmp(value, "current"))
+			push_default = PUSH_DEFAULT_CURRENT;
+		else if (!strcmp(value, "matching"))
+			push_default = PUSH_DEFAULT_MATCHING;
+		else
+			return error("Malformed value for %s", var);
+		return 0;
+	}
+
+	/* Add other config variables here and to Documentation/config.txt. */
+	return 0;
+}
+
 static int git_default_mailmap_config(const char *var, const char *value)
 {
 	if (!strcmp(var, "mailmap.file"))
@@ -588,6 +608,9 @@ int git_default_config(const char *var, const char *value, void *dummy)
 	if (!prefixcmp(var, "branch."))
 		return git_default_branch_config(var, value);
 
+	if (!prefixcmp(var, "push."))
+		return git_default_push_config(var, value);
+
 	if (!prefixcmp(var, "mailmap."))
 		return git_default_mailmap_config(var, value);
 
diff --git a/environment.c b/environment.c
index e278bce..4696885 100644
--- a/environment.c
+++ b/environment.c
@@ -42,6 +42,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
 unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
 enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
 enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
+enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;
 
 /* Parallel index stat data preload? */
 int core_preload_index = 0;
-- 
1.6.2.105.g6ff1f.dirty

[PATCH 3/7] git push: New options --matching and --current

[Finn Arne Gangstad]

--matching: Push all branches that already exist with the same name in
the remote
--current: Push the current branch to whatever it is tracking

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/git-push.txt |   10 +++++-
 builtin-push.c             |   87 +++++++++++++++++++++++++++++++++++---------
 transport.h                |    9 +++++
 3 files changed, 87 insertions(+), 19 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 4e7e5a7..cb7b3d2 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,8 @@ git-push - Update remote refs along with associated objects
 SYNOPSIS
 --------
 [verse]
-'git push' [--all | --mirror | --tags] [--dry-run] [--receive-pack=<git-receive-pack>]
+'git push' [--all | --mirror | --tags | --matching | --current]
+	   [--dry-run] [--receive-pack=<git-receive-pack>]
 	   [--repo=<repository>] [-f | --force] [-v | --verbose]
 	   [<repository> <refspec>...]
 
@@ -82,6 +83,13 @@ nor in any Push line of the corresponding remotes file---see below).
 	if the configuration option `remote.<remote>.mirror` is
 	set.
 
+--matching::
+	For every branch on the local side, the remote side is updated if
+	a branch of the same name already exists there.
+
+--current::
+	Push the current branch to the branch it is tracking on the remote.
+
 --dry-run::
 	Do everything except actually send the updates.
 
diff --git a/builtin-push.c b/builtin-push.c
index 122fdcf..5706c99 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
 #include "parse-options.h"
 
 static const char * const push_usage[] = {
-	"git push [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
+	"git push [--all | --mirror | --current | --matching] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
 	NULL,
 };
 
@@ -48,6 +48,53 @@ static void set_refspecs(const char **refs, int nr)
 	}
 }
 
+static const char *make_push_ref(const char *a, const char *b)
+{
+	char *buf = xmalloc(strlen(a) + strlen(b) + 2);
+	strcpy(buf, a);
+	strcat(buf, ":");
+	strcat(buf, b);
+	return buf;
+}
+
+static void setup_push_current(struct remote *remote)
+{
+	int n;
+	struct branch *branch = branch_get(NULL);
+	if (!branch)
+		die("You are not currently on a branch.");
+	if (!branch->merge_nr)
+		die("The current branch %s is not tracking anything.",
+		    branch->name);
+	if (branch->remote != remote)
+		die("The current branch is tracking \"%s\", not \"%s\"!",
+		    branch->remote->name, remote->name);
+	for (n = 0; n < branch->merge_nr; n++)
+		add_refspec(make_push_ref(branch->name,
+						branch->merge[n]->src));
+}
+
+static void handle_default_push(struct remote *remote, int *flags)
+{
+	git_config(git_default_config, NULL);
+	switch (push_default) {
+	case PUSH_DEFAULT_UNSPECIFIED:
+		/* fallthrough */
+
+	case PUSH_DEFAULT_MATCHING:
+		add_refspec(":");
+		break;
+
+	case PUSH_DEFAULT_CURRENT:
+		setup_push_current(remote);
+		break;
+
+	case PUSH_DEFAULT_NOTHING:
+		die("No refspec given, and none configured.");
+		break;
+	}
+}
+
 static int do_push(const char *repo, int flags)
 {
 	int i, errs;
@@ -59,29 +106,29 @@ static int do_push(const char *repo, int flags)
 	if (remote->mirror)
 		flags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);
 
-	if ((flags & TRANSPORT_PUSH_ALL) && refspec) {
+	if ((flags & TRANSPORT_PUSH_MODE_MASK) && refspec) {
 		if (!strcmp(*refspec, "refs/tags/*"))
-			return error("--all and --tags are incompatible");
-		return error("--all can't be combined with refspecs");
+			return error("--tags cannot be combined with a push mode");
+		return error("push modes cannot be combined with explicit refspecs");
 	}
 
-	if ((flags & TRANSPORT_PUSH_MIRROR) && refspec) {
-		if (!strcmp(*refspec, "refs/tags/*"))
-			return error("--mirror and --tags are incompatible");
-		return error("--mirror can't be combined with refspecs");
-	}
+	if (HAS_MULTI_BITS(flags & TRANSPORT_PUSH_MODE_MASK))
+		return error("Multiple push modes specified");
 
-	if ((flags & (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) ==
-				(TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) {
-		return error("--all and --mirror are incompatible");
-	}
+	if (flags & TRANSPORT_PUSH_CURRENT)
+		setup_push_current(remote);
+	else if (flags & TRANSPORT_PUSH_MATCHING)
+		add_refspec(":");
 
-	if (!refspec
-		&& !(flags & TRANSPORT_PUSH_ALL)
-		&& remote->push_refspec_nr) {
-		refspec = remote->push_refspec;
-		refspec_nr = remote->push_refspec_nr;
+	if (!refspec && !(flags & TRANSPORT_PUSH_MODE_MASK)) {
+		if (remote->push_refspec_nr) {
+			refspec = remote->push_refspec;
+			refspec_nr = remote->push_refspec_nr;
+		} else {
+			handle_default_push(remote, &flags);
+		}
 	}
+
 	errs = 0;
 	for (i = 0; i < remote->url_nr; i++) {
 		struct transport *transport =
@@ -120,6 +167,10 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 		OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
 		OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
 			    (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
+		OPT_BIT( 0 , "matching", &flags, "push all matching refs",
+			 TRANSPORT_PUSH_MATCHING),
+		OPT_BIT( 0 , "current", &flags, "push current branch",
+			 TRANSPORT_PUSH_CURRENT),
 		OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
 		OPT_BIT( 0 , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
 		OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
diff --git a/transport.h b/transport.h
index 6bbc1a8..b897d0c 100644
--- a/transport.h
+++ b/transport.h
@@ -34,6 +34,15 @@ struct transport {
 #define TRANSPORT_PUSH_DRY_RUN 4
 #define TRANSPORT_PUSH_MIRROR 8
 #define TRANSPORT_PUSH_VERBOSE 16
+#define TRANSPORT_PUSH_MATCHING 32
+#define TRANSPORT_PUSH_CURRENT 64
+/**
+ * All push flags that imply a certain set of refspecs to be pushed must
+ * be combined into TRANSPORT_PUSH_MODE_MASK
+ **/
+#define TRANSPORT_PUSH_MODE_MASK \
+    (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR | TRANSPORT_PUSH_MATCHING | \
+    TRANSPORT_PUSH_CURRENT)
 
 /* Returns a transport suitable for the url */
 struct transport *transport_get(struct remote *, const char *);
-- 
1.6.2.105.g6ff1f.dirty

Re: [PATCH 3/7] git push: New options --matching and --current

[Daniel Barkalow]

On Mon, 9 Mar 2009, Finn Arne Gangstad wrote:

> diff --git a/transport.h b/transport.h
> index 6bbc1a8..b897d0c 100644
> --- a/transport.h
> +++ b/transport.h
> @@ -34,6 +34,15 @@ struct transport {
>  #define TRANSPORT_PUSH_DRY_RUN 4
>  #define TRANSPORT_PUSH_MIRROR 8
>  #define TRANSPORT_PUSH_VERBOSE 16
> +#define TRANSPORT_PUSH_MATCHING 32
> +#define TRANSPORT_PUSH_CURRENT 64
> +/**
> + * All push flags that imply a certain set of refspecs to be pushed must
> + * be combined into TRANSPORT_PUSH_MODE_MASK
> + **/
> +#define TRANSPORT_PUSH_MODE_MASK \
> +    (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR | TRANSPORT_PUSH_MATCHING | \
> +    TRANSPORT_PUSH_CURRENT)

It's kind of odd that you define these flags as TRANSPORT_PUSH_*, but 
implement them before entering transport_push(). I'm not sure which is 
right, but the combination is odd. I think just taking care of it in 
builtin-push with flags or options defined there is probably the best 
thing, currently.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH 3/7] git push: New options --matching and --current

[Finn Arne Gangstad]

On Mon, Mar 09, 2009 at 07:49:47PM -0400, Daniel Barkalow wrote:
> On Mon, 9 Mar 2009, Finn Arne Gangstad wrote:
> 
> > diff --git a/transport.h b/transport.h
> > index 6bbc1a8..b897d0c 100644
> > --- a/transport.h
> > +++ b/transport.h
> > @@ -34,6 +34,15 @@ struct transport {
> >  #define TRANSPORT_PUSH_DRY_RUN 4
> >  #define TRANSPORT_PUSH_MIRROR 8
> >  #define TRANSPORT_PUSH_VERBOSE 16
> > +#define TRANSPORT_PUSH_MATCHING 32
> > +#define TRANSPORT_PUSH_CURRENT 64
> > +/**
> > + * All push flags that imply a certain set of refspecs to be pushed must
> > + * be combined into TRANSPORT_PUSH_MODE_MASK
> > + **/
> > +#define TRANSPORT_PUSH_MODE_MASK \
> > +    (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR | TRANSPORT_PUSH_MATCHING | \
> > +    TRANSPORT_PUSH_CURRENT)
> 
> It's kind of odd that you define these flags as TRANSPORT_PUSH_*, but 
> implement them before entering transport_push(). I'm not sure which is 
> right, but the combination is odd. I think just taking care of it in 
> builtin-push with flags or options defined there is probably the best 
> thing, currently.

True, this was not very beautiful. I will make something better.

- Finn Arne

[PATCH 4/7] git push: Display warning on unconfigured default push

[Finn Arne Gangstad]

As a preparation for a possible future "git push" default behaviour change,
display a prominent warning for operations that may change behaviour
in the future. The warning explains for the user how to configure this
permanently so the warning will not be seen again after proper configuration.

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 builtin-push.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/builtin-push.c b/builtin-push.c
index 5706c99..b9fe206 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -74,11 +74,34 @@ static void setup_push_current(struct remote *remote)
 						branch->merge[n]->src));
 }
 
+static const char *warn_unconfigured_push_msg[] = {
+	"You did not specify any refspecs to push, and the current remote",
+	"has not configured any push refspecs. The default action in this",
+	"case has been to push all matching refspecs, that is, all branches",
+	"that exist both locally and remotely will be updated.",
+	"This default may change in the future.",
+	"",
+	"You can specify what action you want to take in this case, and",
+	"avoid seeing this message again, by configuring 'push.default' to:",
+	"  'nothing'  : Do not push anythig",
+	"  'matching' : Push all matching branches (the current default)",
+	"  'current'  : Push the current branch to whatever it is tracking",
+	""
+};
+
+static void warn_unconfigured_push()
+{
+	int i;
+	for (i = 0; i < ARRAY_SIZE(warn_unconfigured_push_msg); i++)
+		warning("%s", warn_unconfigured_push_msg[i]);
+}
+
 static void handle_default_push(struct remote *remote, int *flags)
 {
 	git_config(git_default_config, NULL);
 	switch (push_default) {
 	case PUSH_DEFAULT_UNSPECIFIED:
+		warn_unconfigured_push();
 		/* fallthrough */
 
 	case PUSH_DEFAULT_MATCHING:
-- 
1.6.2.105.g6ff1f.dirty

Re: [PATCH 4/7] git push: Display warning on unconfigured default push

[Jay Soffian]

On Mon, Mar 9, 2009 at 6:35 PM, Finn Arne Gangstad <finnag@pvv.org> wrote:
> +       "  'nothing'  : Do not push anythig",

s/anythig/anything/

j.

[PATCH 5/7] git push: Document that "nothing" is the future push default

[Finn Arne Gangstad]

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/RelNotes-1.6.3.txt |    7 +++++++
 builtin-push.c                   |    4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/Documentation/RelNotes-1.6.3.txt b/Documentation/RelNotes-1.6.3.txt
index ee1fddb..87de02a 100644
--- a/Documentation/RelNotes-1.6.3.txt
+++ b/Documentation/RelNotes-1.6.3.txt
@@ -22,6 +22,13 @@ branch pointed at by its HEAD, gets a large warning.  You can choose what
 should happen upon such a push by setting the configuration variable
 receive.denyDeleteCurrent in the receiving repository.
 
+In a future release, the default of "git push" without further
+arguments will be to push nothing. Currently, it will push all
+matching refspecs to the current remote.  A configuration variable
+push.default has been introduced to select the default behaviour.  To
+ease the transition, a big warning is issued if this is not configured
+and a git push without arguments is attempted.
+
 
 Updates since v1.6.2
 --------------------
diff --git a/builtin-push.c b/builtin-push.c
index b9fe206..7ef499f 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -79,11 +79,11 @@ static const char *warn_unconfigured_push_msg[] = {
 	"has not configured any push refspecs. The default action in this",
 	"case has been to push all matching refspecs, that is, all branches",
 	"that exist both locally and remotely will be updated.",
-	"This default may change in the future.",
+	"This default will change in the future.",
 	"",
 	"You can specify what action you want to take in this case, and",
 	"avoid seeing this message again, by configuring 'push.default' to:",
-	"  'nothing'  : Do not push anythig",
+	"  'nothing'  : Do not push anythig (the future default)",
 	"  'matching' : Push all matching branches (the current default)",
 	"  'current'  : Push the current branch to whatever it is tracking",
 	""
-- 
1.6.2.105.g6ff1f.dirty

[PATCH 6/7] git push: Change default for "git push" to nothing.

[Finn Arne Gangstad]

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/config.txt   |    4 ++--
 Documentation/git-push.txt |    4 +---
 builtin-push.c             |    7 ++++---
 3 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 50bc1d0..437216c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1170,10 +1170,10 @@ push.default::
 	branch, or `origin` if no remote is configured. `origin` is also used
 	if you are not on any branch.
 +
-* `nothing` do not push anything
+* `nothing` do not push anything.  This is new the default value.
 * `matching` push all matching branches to the current remote.
   All branches having the same name in both ends are considered to be
-  matching. This is the default value.
+  matching.  This used to be the default value.
 * `current` push the current branch to the branch it is tracking on
   the remote
 
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index cb7b3d2..149c1f0 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -64,9 +64,7 @@ the remote repository.
 The special refspec `:` (or `{plus}:` to allow non-fast forward updates)
 directs git to push "matching" branches: for every branch that exists on
 the local side, the remote side is updated if a branch of the same name
-already exists on the remote side.  This is the default operation mode
-if no explicit refspec is found (that is neither on the command line
-nor in any Push line of the corresponding remotes file---see below).
+already exists on the remote side.
 
 --all::
 	Instead of naming each ref to push, specifies that all
diff --git a/builtin-push.c b/builtin-push.c
index 7ef499f..93f12a8 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -104,6 +104,10 @@ static void handle_default_push(struct remote *remote, int *flags)
 		warn_unconfigured_push();
 		/* fallthrough */
 
+	case PUSH_DEFAULT_NOTHING:
+		die("No refspec given, and none configured.");
+		break;
+
 	case PUSH_DEFAULT_MATCHING:
 		add_refspec(":");
 		break;
@@ -112,9 +116,6 @@ static void handle_default_push(struct remote *remote, int *flags)
 		setup_push_current(remote);
 		break;
 
-	case PUSH_DEFAULT_NOTHING:
-		die("No refspec given, and none configured.");
-		break;
 	}
 }
 
-- 
1.6.2.105.g6ff1f.dirty

[PATCH 7/7] git push: Remove warning for "git push" default change

[Finn Arne Gangstad]

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/config.txt |    4 ++--
 builtin-push.c           |   27 ---------------------------
 cache.h                  |    1 -
 environment.c            |    2 +-
 4 files changed, 3 insertions(+), 31 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 437216c..d110edc 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1170,10 +1170,10 @@ push.default::
 	branch, or `origin` if no remote is configured. `origin` is also used
 	if you are not on any branch.
 +
-* `nothing` do not push anything.  This is new the default value.
+* `nothing` do not push anything.  This is the default value.
 * `matching` push all matching branches to the current remote.
   All branches having the same name in both ends are considered to be
-  matching.  This used to be the default value.
+  matching.
 * `current` push the current branch to the branch it is tracking on
   the remote
 
diff --git a/builtin-push.c b/builtin-push.c
index 93f12a8..d0ab76d 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -74,36 +74,10 @@ static void setup_push_current(struct remote *remote)
 						branch->merge[n]->src));
 }
 
-static const char *warn_unconfigured_push_msg[] = {
-	"You did not specify any refspecs to push, and the current remote",
-	"has not configured any push refspecs. The default action in this",
-	"case has been to push all matching refspecs, that is, all branches",
-	"that exist both locally and remotely will be updated.",
-	"This default will change in the future.",
-	"",
-	"You can specify what action you want to take in this case, and",
-	"avoid seeing this message again, by configuring 'push.default' to:",
-	"  'nothing'  : Do not push anythig (the future default)",
-	"  'matching' : Push all matching branches (the current default)",
-	"  'current'  : Push the current branch to whatever it is tracking",
-	""
-};
-
-static void warn_unconfigured_push()
-{
-	int i;
-	for (i = 0; i < ARRAY_SIZE(warn_unconfigured_push_msg); i++)
-		warning("%s", warn_unconfigured_push_msg[i]);
-}
-
 static void handle_default_push(struct remote *remote, int *flags)
 {
 	git_config(git_default_config, NULL);
 	switch (push_default) {
-	case PUSH_DEFAULT_UNSPECIFIED:
-		warn_unconfigured_push();
-		/* fallthrough */
-
 	case PUSH_DEFAULT_NOTHING:
 		die("No refspec given, and none configured.");
 		break;
@@ -115,7 +89,6 @@ static void handle_default_push(struct remote *remote, int *flags)
 	case PUSH_DEFAULT_CURRENT:
 		setup_push_current(remote);
 		break;
-
 	}
 }
 
diff --git a/cache.h b/cache.h
index 3a6acb8..f3f8e28 100644
--- a/cache.h
+++ b/cache.h
@@ -542,7 +542,6 @@ enum rebase_setup_type {
 };
 
 enum push_default_type {
-	PUSH_DEFAULT_UNSPECIFIED = -1,
 	PUSH_DEFAULT_NOTHING = 0,
 	PUSH_DEFAULT_MATCHING,
 	PUSH_DEFAULT_CURRENT,
diff --git a/environment.c b/environment.c
index 4696885..6766394 100644
--- a/environment.c
+++ b/environment.c
@@ -42,7 +42,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
 unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
 enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
 enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
-enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;
+enum push_default_type push_default = PUSH_DEFAULT_NOTHING;
 
 /* Parallel index stat data preload? */
 int core_preload_index = 0;
-- 
1.6.2.105.g6ff1f.dirty

Re: [RFC/PATCH] git push usability improvements and default change

[Johannes Schindelin]

Hi,

On Mon, 9 Mar 2009, Finn Arne Gangstad wrote:

> git push default change:
> 
> git push will by default push "nothing" instead of "matching".

Hasn't this been shot down already?  I do not want that change.  I think 
it is harmful.

At least without a proper way to prepare existing users for the end of the 
world.

Ciao,
Dscho

Re: [RFC/PATCH] git push usability improvements and default change

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> git push default change:
>> 
>> git push will by default push "nothing" instead of "matching".
>
> Hasn't this been shot down already?  I do not want that change.  I think 
> it is harmful.
>
> At least without a proper way to prepare existing users for the end of the 
> world.

I haven't actually read the patch, but my reading of the cover lette ris
that the four-patch sequence 4-to-7 is (meant to be, at least) structured
that way.

Re: [RFC/PATCH] git push usability improvements and default change

[Finn Arne Gangstad]

On Tue, Mar 10, 2009 at 12:35:12AM +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 9 Mar 2009, Finn Arne Gangstad wrote:
> 
> > git push default change:
> > 
> > git push will by default push "nothing" instead of "matching".
> 
> Hasn't this been shot down already?  I do not want that change.  I think 
> it is harmful.
> 
> At least without a proper way to prepare existing users for the end of the 
> world.

That is pretty much what patches 4 and 5 are about - add nice
warnings, but do not change behavior. 6 introduces the changed default.

- Finn Arne

Re: [RFC/PATCH] git push usability improvements and default change

[Johannes Schindelin]

Hi,

On Tue, 10 Mar 2009, Finn Arne Gangstad wrote:

> On Tue, Mar 10, 2009 at 12:35:12AM +0100, Johannes Schindelin wrote:
> 
> > On Mon, 9 Mar 2009, Finn Arne Gangstad wrote:
> > 
> > > git push default change:
> > > 
> > > git push will by default push "nothing" instead of "matching".
> > 
> > Hasn't this been shot down already?  I do not want that change.  I 
> > think it is harmful.
> > 
> > At least without a proper way to prepare existing users for the end of 
> > the world.
> 
> That is pretty much what patches 4 and 5 are about - add nice warnings, 
> but do not change behavior. 6 introduces the changed default.

Ah, so you meant that 1-5 should be committed right away, and 6 in one 
year?

Ciao,
Dscho

Re: [RFC/PATCH] git push usability improvements and default change

[Finn Arne Gangstad]

On Tue, Mar 10, 2009 at 12:01:00PM +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 10 Mar 2009, Finn Arne Gangstad wrote:
> 
> > On Tue, Mar 10, 2009 at 12:35:12AM +0100, Johannes Schindelin wrote:
> > 
> > > [...]
> > > At least without a proper way to prepare existing users for the end of 
> > > the world.
> > 
> > That is pretty much what patches 4 and 5 are about - add nice warnings, 
> > but do not change behavior. 6 introduces the changed default.
> 
> Ah, so you meant that 1-5 should be committed right away, and 6 in one 
> year?

Yes, that was the intention.

- Finn Arne

Re: [RFC/PATCH] git push usability improvements and default change

[Junio C Hamano]

Finn Arne Gangstad <finnag@pvv.org> writes:

> "-" is now an alias for the current remote (the remote of the current
> branch or "origin" as a fallback). This works both for push, fetch,
> pull, remote (and possibly some others), creating a lot of nice
> shortcuts I think:
> git remote prune - : prune the current remote
> git push - HEAD : push the current branch to a branch of the same name
> git fetch - next : fetch the next branch from the current remote
>
> git push has learned two new command line options --matching and
> --current, which override any configuration.  'matching' pushes all
> branches that already exist at the remote, while 'current' pushes the
> current branch to whatever it is tracking
>
> I chose this behaviour for 'current', since it is the one that I find
> most useful, and there seems to be no good way of expressing it from
> the command line.  Pushing a branch to an identically named branch on
> a remote can now easily be done by "git push - HEAD".
>
> Also added a new configuration option push.default, which can have values
> "nothing", "matching" and "current". This variable will only be used if
> you have not specificed any refspecs at all, no command line options imply
> any refspecs, and the current branch has no push configuration.
>
> This is implemented in 1-3

I think the last four are more or less sane, but I am not sure about the
first three, which makes it very unfortunate that the former depends on
the latter.

Some design issues and questions regarding the first three; not all of
them are objections:

 * Do we use a short-hand for "the default thing" anywhere else in the
   current UI (not just "git push" but in the "git" command set)?

   - If the answer to the above question is "yes", does it use '-' as the
     short-hand too?  In other words, is this new short-hand consistent
     with it, or is it introducing "git-push uses '-' as the short-hand
     for the default, while git-frotz uses something else" confusion?

   - Even if the answer to the above question is "no", are there other
     commands that we currently do not allow a quick shorthand to mean
     "the default thing", but would benefit from having one?  If so, how
     good does it look to use '-' as such a short-hand?

     In other words, is it safe to establish a precedent to use '-' to
     denote "the default thing"?  Would we later regret, saying that
     "'git-frotz command would benefit from a short-hand notation for 'the
     default thing', but - is already taken -- it means send the output to
     the stdout"?

   - Do we use a short-hand '-' to mean something entirely different in
     the UI, making this new use of '-' to mean the default confusing?

     I think '-' for checkout means "the previous one", which already
     answers this question somewhat.

 * What's the point of having --matching option, when you can already say
   ':', i.e.

	$ git push origin :

 * What's the point of having --current option, when you can already say
   HEAD, i.e.

	$ git push origin HEAD

 * Is push.default still necessary if we had "remote.*.push" (where '*' is
   literally an "asterisk") that is used as a fall-back default when there
   is no "remote.<name>.push" for the remote we are about to push to?

Re: [RFC/PATCH] git push usability improvements and default change

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>    - Even if the answer to the above question is "no", are there other
>      commands that we currently do not allow a quick shorthand to mean
>      "the default thing", but would benefit from having one?  If so, how
>      good does it look to use '-' as such a short-hand?

I need " for these other commands" before the question mark at the end of
this sentence.

>      In other words, is it safe to establish a precedent to use '-' to
>      denote "the default thing"?  Would we later regret, saying that
>      "'git-frotz command would benefit from a short-hand notation for 'the
>      default thing', but - is already taken -- it means send the output to
>      the stdout"?

I need ", or something like that" before the question mark at the end of
this sentence.

>    - Do we use a short-hand '-' to mean something entirely different in
>      the UI, making this new use of '-' to mean the default confusing?
>
>      I think '-' for checkout means "the previous one", which already
>      answers this question somewhat.

I am wondering if we can handle this by DWIMming the command line
arguments better.  For example, in all of these:

	$ git push HEAD
        $ git push :
        $ git push master

when "HEAD", ":", or "master" can only be refspec, we know that the user
said "I do not bother saying which repository to --- you know what I
mean."  It would be natural to DWIM it to "the default remote" without
even having to use your '-' notation.

Re: [RFC/PATCH] git push usability improvements and default change

[Finn Arne Gangstad]

On Mon, Mar 09, 2009 at 05:07:08PM -0700, Junio C Hamano wrote:
> Finn Arne Gangstad <finnag@pvv.org> writes:
> 
> I think the last four are more or less sane, but I am not sure about the
> first three, which makes it very unfortunate that the former depends on
> the latter.

No problem splitting them up, there is just a single function that is
shared between 1-3 and 4-7 really.

[...]
>  * What's the point of having --matching option, when you can already say
>    ':', i.e.
> 
> 	$ git push origin :

If you have the name of your remote easily available, --matching is
identical to "git push remote :". As I believe I found out, getting
the name of the current remote is a bit more tedious than it should
be, which is why I also suggested being able to use "-" as the current
remote.

If a way to specify the default remote is possible, --matching would
not be necessary, but would probably be more obvious to the reader
than "git push - :" or whatever we can agree on.

>  * What's the point of having --current option, when you can already
> say HEAD, i.e.  $ git push origin HEAD

It does something very different. Maybe --tracking would be a better name.
--current does basically this:

branch=`git-symbolic-ref HEAD`
branch=${branch#refs/heads/}
remote=$(git config branch.$branch.remote)

for remotebranch in $(git config branch.$branch.merge); do
	git push $remote $branch:$remotebranch
done

This is the shortest shell script sequence I could find to mimic the
behaviour, maybe I have missed something very obvious. All error
handling is removed for clarity.

The goal here is to be able to:

git checkout -b junios-next origin/next
git push --current  <=>  git push origin junios-next:next

git push origin HEAD would do git push origin junios-next:junios-next,
which was not the intention.

It seems that there is an assumption that branch names are identical
in different repositories, we find that that is not the case at all,
people choose local names that make sense to themselves. Or, from
another viewpoint, even if branches have the same name in two
repositories, they are not necessarily (strongly) related!

"A tracks B" can be a much stronger relation than "A has the same name
as B".

>  * Is push.default still necessary if we had "remote.*.push" (where '*' is
>    literally an "asterisk") that is used as a fall-back default when there
>    is no "remote.<name>.push" for the remote we are about to push to?

The main reason for push.default is to be able to change the default
behaviour for git push to push nothing in a staged manner, and still
let people who are used to and fond of the old behavior continue as before.

You are thinking of something like this in .gitconfig?
[remote "*"]
	push = __something__

Previously you indicated that there is no way to specify the current
matching rule in a remote push line I think?

- Finn Arne

Re: [RFC/PATCH] git push usability improvements and default change

[Jay Soffian]

On Tue, Mar 10, 2009 at 6:04 AM, Finn Arne Gangstad <finnag@pvv.org> wrote:
> You are thinking of something like this in .gitconfig?
> [remote "*"]
>        push = __something__
>
> Previously you indicated that there is no way to specify the current
> matching rule in a remote push line I think?

No, you can. "push = :" works fine.

However, there's no way to specify "push = nothing" currently.

FWIW, I don't care for using remote.*.push for this use case. I think
push.default is clearer here.

j.

Re: [RFC/PATCH] git push usability improvements and default change

[Junio C Hamano]

Finn Arne Gangstad <finnag@pvv.org> writes:

> On Mon, Mar 09, 2009 at 05:07:08PM -0700, Junio C Hamano wrote:
> ...
>>  * What's the point of having --current option, when you can already
>> say HEAD, i.e.  $ git push origin HEAD
>
> It does something very different. Maybe --tracking would be a better name.
> --current does basically this:
> ...
> The goal here is to be able to:
>
> git checkout -b junios-next origin/next
> git push --current  <=>  git push origin junios-next:next
>
> git push origin HEAD would do git push origin junios-next:junios-next,
> which was not the intention.

Ok, now that sort of makes sense, and is very different from people would
expect from --current, which I think most people would associate with
HEAD.  "tracking" or "track back" would be a better name.

Re: [RFC/PATCH] git push usability improvements and default change

[Nanako Shiraishi]

Quoting Junio C Hamano <gitster@pobox.com>:

> Finn Arne Gangstad <finnag@pvv.org> writes:
>
>> On Mon, Mar 09, 2009 at 05:07:08PM -0700, Junio C Hamano wrote:
>> ...
>>>  * What's the point of having --current option, when you can already
>>> say HEAD, i.e.  $ git push origin HEAD
>>
>> It does something very different. Maybe --tracking would be a better name.
>> --current does basically this:
>> ...
>> The goal here is to be able to:
>>
>> git checkout -b junios-next origin/next
>> git push --current  <=>  git push origin junios-next:next
>>
>> git push origin HEAD would do git push origin junios-next:junios-next,
>> which was not the intention.
>
> Ok, now that sort of makes sense, and is very different from people would
> expect from --current, which I think most people would associate with
> HEAD.  "tracking" or "track back" would be a better name.

I think this proposal has deeper problems than just that.

There can be two reasons you may want to give the branch a name other than 'next':

1. Because you also have dschos-next that tracks remotes/dscho/next; or

2. Because you also have junios-next2 that also tracks remotes/origin/next.

The first case indicates that the project is using a workflow where each developer has his own publishing repository [1], and it is very unlikely that Finn Arne has push access to either your or Johannes'es public repositories.

The second case of tracking a single branch with more than one is unnecessarily confusing. If you are on junios-next and you push (and we assume that you are Junio and have push access to the remote repository), after such a push you need to update junios-next2 somehow, either by rebasing or by merging. The reason junios-next2 branch needs updating is because it has changes unrelated to what you pushed out from your junios-next branch to the outside world as 'next'.

In such a case, wouldn't it be much easier to understand and manage if you had a single 'next' branch that has changes ready to be shown to the remote 'next', and make other topic branches fork from and track your local 'next' instead?

Your changes based on the public 'next' that everybody else sees need to get first integrated and tested in your local repository before getting pushed out to the remote 'next' branch in any case.

You certainly could switch between junios-next and junios-next2 branches that both track the public 'next' branch, and make sure you will integrate everything you need to send to the public repository no matter what branch you are currently working on. Unless you do so, 'git push' will refuse to accept an update that isn't a fast-forward anyway, so it certainly possible to work with more than one local branches that track a single remote branch.

But in order to do this correctly, you need to be aware what each branch is meant to contain, and for which public branch you are developing your changes on it. I think that way of working leads to the confusion and perceived need for the "--current" option: "I don't know which remote branch the changes I made on the current branch should be pushed to, and --current option remembers it for me, so I don't have to". That new option may be solving "where to push to" part but I'm afraid the option not just leaves "I still need to know for which public branch I am supposed to make changes while on this branch" unsolved, but by making people rely on the option I think it makes the latter problem much worse.

Dedicating your local 'next' for the integration purpose to prepare what you push to your public 'next' is much easier to understand and explain to new people. Once a topic that is meant to be published on your 'next' becomes ready, you merge the branch locally to your own 'next', and you have a chance to review that you didn't accidentally included changes inappropriate for 'next' when you create the merge. You push the result out after you are happy.

And I think the above discussion holds true if the public 'next' isn't your 'next', but a branch shared with others in a central repository.

I don't understand how the new "--current" makes "sort-of" sense. It looks like it is making the command more complex and the only thing it does is to encourage a confused workflow.

[1] Your http://gitster.livejournal.com/30645.html showed different ways to collaborate very nicely. I think this is the third approach in your article.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: [RFC/PATCH] git push usability improvements and default change

[Finn Arne Gangstad]

On Thu, Mar 12, 2009 at 12:01:09PM +0900, Nanako Shiraishi wrote:

[...]
> There can be two reasons you may want to give the branch a name other than 'next':
> 
> 1. Because you also have dschos-next that tracks remotes/dscho/next; or
> 
> 2. Because you also have junios-next2 that also tracks remotes/origin/next.

> The first case indicates that the project is using a workflow where
> each developer has his own publishing repository [1], and it is very
> unlikely that Finn Arne has push access to either your or
> Johannes'es public repositories.

No, think more of different repositories with different function, such
as "my-public", "my-group", "beta", "customers", "public" and so on.
You can have multiple repositories with different function. They (can)
have branches with the same name, but have different purposes. To
track more than one you _must_ rename at least one locally (and just
with two remotes "master" is going to give you some issues).

Maybe you want the name in the public repo to be different than the
name in your own repo.

[...]

> I don't understand how the new "--current" makes "sort-of" sense. It
> looks like it is making the command more complex and the only thing
> it does is to encourage a confused workflow.

The naming --current was not good, so I have changed it to --tracking
in my latest suggestion.  Why is it confused?  Why do I need to call
my branch locally the same as it is named remotely?  That does not
scale. Branch names are unique per repository, not globally.

I want to be able to "git pull" and then "git push --tracking" back to
the same branch, not push somewhere else. Curently this requires a
surprisingly complicated shellscript, and is not available from the
guis.

> [1] Your http://gitster.livejournal.com/30645.html showed different
> ways to collaborate very nicely. I think this is the third approach
> in your article.

The main problem with all these examples is that the underlying
assumption is that you can always use the same branch name locally and
remotely.  This just isn't always the case when you have many remotes,
and each remote repository has some implicit function (e.g. "beta",
"john", "graphics-group", "my-public", .....), and they have an active
"master" branch for example.

- Finn Arne

Re: [RFC/PATCH] git push usability improvements and default change

[Miles Bader]

Finn Arne Gangstad <finnag@pvv.org> writes:
> The main problem with all these examples is that the underlying
> assumption is that you can always use the same branch name locally and
> remotely.

Presumably the push --track option would be used with an explicit branch
name given to push anyway, right?  Then it can use that info to set up
the tracking flexibly (and with sane defaults).

E.g.,, simple case:

    git push --track SOME_REMOTE BRANCH_NAME

complex case:

    git push --track SOME_REMOTE MY-BRANCH:REMOTE-BRANCH

-Miles

-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

Re: [RFC/PATCH] git push usability improvements and default change

[Finn Arne Gangstad]

On Thu, Mar 12, 2009 at 07:52:29PM +0900, Miles Bader wrote:
> Finn Arne Gangstad <finnag@pvv.org> writes:
> > The main problem with all these examples is that the underlying
> > assumption is that you can always use the same branch name locally and
> > remotely.
> 
> Presumably the push --track option would be used with an explicit branch
> name given to push anyway, right?  Then it can use that info to set up
> the tracking flexibly (and with sane defaults).
> 
> E.g.,, simple case:
> 
>     git push --track SOME_REMOTE BRANCH_NAME
> 
> complex case:
> 
>     git push --track SOME_REMOTE MY-BRANCH:REMOTE-BRANCH

Yes, git push --track ... would typically do the same thing to the
config as git checkout -b MY-BRANCH SOME_REMOTE/REMOTE-BRANCH, which
is enough for push --tracking to do its thing.

I am not sure if you mean that git push --track could do something
extra to make --tracking unecessary for git push, currently it cannot
do that since the push configuration is per remote, not per branch.

- Finn Arne

Re: [RFC/PATCH] git push usability improvements and default change

[Miles Bader]

Finn Arne Gangstad <finnag@pvv.org> writes:
>> Presumably the push --track option would be used with an explicit branch
>> name given to push anyway, right?  Then it can use that info to set up
>> the tracking flexibly (and with sane defaults).
>> 
>> E.g.,, simple case:
>>     git push --track SOME_REMOTE BRANCH_NAME
>> 
>> complex case:
>>     git push --track SOME_REMOTE MY-BRANCH:REMOTE-BRANCH
>
> Yes, git push --track ... would typically do the same thing to the
> config as git checkout -b MY-BRANCH SOME_REMOTE/REMOTE-BRANCH, which
> is enough for push --tracking to do its thing.
>
> I am not sure if you mean that git push --track could do something
> extra to make --tracking unecessary for git push, currently it cannot
> do that since the push configuration is per remote, not per branch.

Hmm, now I'm confused... I was just thinking about --track, but am not
sure what --tracking is ... need to go grovel past posts...

-Miles

-- 
Happiness, n. An agreeable sensation arising from contemplating the misery of
another.

Re: [RFC/PATCH] git push usability improvements and default change

[John Tapsell]

Hi,

   What's the status of these patches?  Will be commited?

John

2009/3/13 Miles Bader <miles@gnu.org>:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>>> Presumably the push --track option would be used with an explicit branch
>>> name given to push anyway, right?  Then it can use that info to set up
>>> the tracking flexibly (and with sane defaults).
>>>
>>> E.g.,, simple case:
>>>     git push --track SOME_REMOTE BRANCH_NAME
>>>
>>> complex case:
>>>     git push --track SOME_REMOTE MY-BRANCH:REMOTE-BRANCH
>>
>> Yes, git push --track ... would typically do the same thing to the
>> config as git checkout -b MY-BRANCH SOME_REMOTE/REMOTE-BRANCH, which
>> is enough for push --tracking to do its thing.
>>
>> I am not sure if you mean that git push --track could do something
>> extra to make --tracking unecessary for git push, currently it cannot
>> do that since the push configuration is per remote, not per branch.
>
> Hmm, now I'm confused... I was just thinking about --track, but am not
> sure what --tracking is ... need to go grovel past posts...
>
> -Miles
>
> --
> Happiness, n. An agreeable sensation arising from contemplating the misery of
> another.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [RFC/PATCH] git push usability improvements and default change

[Jeff King]

On Mon, Mar 09, 2009 at 11:35:44PM +0100, Finn Arne Gangstad wrote:

> git push has learned two new command line options --matching and
> --current, which override any configuration.  'matching' pushes all
> branches that already exist at the remote, while 'current' pushes the
> current branch to whatever it is tracking

I have not been following this topic too closely, so can you please
explain (or point me to an explanation about) something? How do these
options interact with refspecs given on the command line? That is, why
would I choose to use:

  git push --current

over

  git push - HEAD

(assuming your earlier patch is applied, or "git push HEAD" if Junio's
suggested DWIMmery is implemented). And what does it mean to say

  git push --matching - HEAD

? Those are conflicting instructions. Is one followed and one discarded?
Are they merged?

-Peff

Re: [RFC/PATCH] git push usability improvements and default change

[Finn Arne Gangstad]

On Tue, Mar 10, 2009 at 01:52:33PM -0400, Jeff King wrote:
> 
> I have not been following this topic too closely, so can you please
> explain (or point me to an explanation about) something? How do these
> options interact with refspecs given on the command line? That is, why
> would I choose to use:
> 
>   git push --current
> 
> over
> 
>   git push - HEAD

--current pushs the current branch to whatever it is tracking, no
matter what name it has (i.e. it can push to a branch of different
name). If it is not tracking anything, it will not push.

git push - HEAD pushes the current branch to a branch of the same name
on the "current remote", which defaults to origin if nothing is set up
for the branch.

> (assuming your earlier patch is applied, or "git push HEAD" if Junio's
> suggested DWIMmery is implemented). And what does it mean to say
> 
>   git push --matching - HEAD
> 
> ? Those are conflicting instructions. Is one followed and one discarded?
> Are they merged?

It would be an error, no refspecs can be specified with --matching.

- Finn Arne

Re: [RFC/PATCH] git push usability improvements and default change

[Jeff King]

On Tue, Mar 10, 2009 at 11:04:00PM +0100, Finn Arne Gangstad wrote:

> --current pushs the current branch to whatever it is tracking, no
> matter what name it has (i.e. it can push to a branch of different
> name). If it is not tracking anything, it will not push.
> 
> git push - HEAD pushes the current branch to a branch of the same name
> on the "current remote", which defaults to origin if nothing is set up
> for the branch.

OK, that's what I was missing. Thanks.

-Peff

Re: [RFC/PATCH] git push usability improvements and default change

[Jay Soffian]

On Tue, Mar 10, 2009 at 6:04 PM, Finn Arne Gangstad <finnag@pvv.org> wrote:
> --current pushs the current branch to whatever it is tracking, no
> matter what name it has (i.e. it can push to a branch of different
> name). If it is not tracking anything, it will not push.

I think the option is definitely misnamed then. If it survives the
list feedback, it should probably be called something like --tracked.

j.