[RFC PATCH] git push: Push nothing if no refspecs are given or configured

[RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Finn Arne Gangstad]

Previously, git push [remote] with no arguments would behave like
"git push <remote> :" if no push refspecs were configured for the remote.
It may be too easy for novice users to write "git push" or
"git push origin" by accident, so git will now push nothing, and give an
error message in such cases.

Teach git push a new option "--matching" that keeps the old behavior of
pushing all matching branches when none are configured.

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

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 4e7e5a7..77a4792 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ 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 | --matching | --tags] [--dry-run] [--receive-pack=<git-receive-pack>]
 	   [--repo=<repository>] [-f | --force] [-v | --verbose]
 	   [<repository> <refspec>...]
 
@@ -63,10 +63,11 @@ 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
+already exists on the remote side. Nothing will be pushed
 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).
 
+
 --all::
 	Instead of naming each ref to push, specifies that all
 	refs under `$GIT_DIR/refs/heads/` be pushed.
@@ -82,6 +83,11 @@ nor in any Push line of the corresponding remotes file---see below).
 	if the configuration option `remote.<remote>.mirror` is
 	set.
 
+--matching::
+	If no explicit refspecs are given, and no push refspecs are
+	configured for the remote, push all matching branches
+	(branches that exist in both ends) instead of nothing.
+
 --dry-run::
 	Do everything except actually send the updates.
 
diff --git a/builtin-push.c b/builtin-push.c
index 122fdcf..ffc648d 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 | --matching] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
 	NULL,
 };
 
@@ -48,6 +48,12 @@ static void set_refspecs(const char **refs, int nr)
 	}
 }
 
+
+static int has_multiple_bits(unsigned int x)
+{
+	return (x & (x - 1)) != 0;
+}
+
 static int do_push(const char *repo, int flags)
 {
 	int i, errs;
@@ -71,17 +77,24 @@ static int do_push(const char *repo, int flags)
 		return error("--mirror can't be combined with refspecs");
 	}
 
-	if ((flags & (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) ==
-				(TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) {
-		return error("--all and --mirror are incompatible");
+	if (has_multiple_bits(flags & (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR | TRANSPORT_PUSH_MATCHING))) {
+		return error("--all, --mirror and --matching are incompatible");
 	}
 
-	if (!refspec
-		&& !(flags & TRANSPORT_PUSH_ALL)
-		&& remote->push_refspec_nr) {
-		refspec = remote->push_refspec;
-		refspec_nr = remote->push_refspec_nr;
+	if ((flags & TRANSPORT_PUSH_MATCHING)  && refspec) {
+		return error("--matching cannot be combined with refspecs");
 	}
+
+
+	if (!refspec && !(flags & TRANSPORT_PUSH_ALL)) {
+		if (remote->push_refspec_nr) {
+			refspec = remote->push_refspec;
+			refspec_nr = remote->push_refspec_nr;
+		} else if (!(flags & TRANSPORT_PUSH_MATCHING)) {
+			return error("No refspecs given and none configured for %s, nothing to push.", remote->name);
+		}
+	}
+
 	errs = 0;
 	for (i = 0; i < remote->url_nr; i++) {
 		struct transport *transport =
@@ -120,6 +133,7 @@ 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_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..fb98128 100644
--- a/transport.h
+++ b/transport.h
@@ -34,6 +34,7 @@ struct transport {
 #define TRANSPORT_PUSH_DRY_RUN 4
 #define TRANSPORT_PUSH_MIRROR 8
 #define TRANSPORT_PUSH_VERBOSE 16
+#define TRANSPORT_PUSH_MATCHING 32
 
 /* Returns a transport suitable for the url */
 struct transport *transport_get(struct remote *, const char *);
-- 
1.6.2.12.g83676.dirty

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Sverre Rabbelier]

Heya,

On Thu, Mar 5, 2009 at 23:15, Finn Arne Gangstad <finnag@pvv.org> wrote:
> Previously, git push [remote] with no arguments would behave like
> "git push <remote> :" if no push refspecs were configured for the remote.
> It may be too easy for novice users to write "git push" or
> "git push origin" by accident, so git will now push nothing, and give an
> error message in such cases.

Config option please, I very much like the current behavior.

-- 
Cheers,

Sverre Rabbelier

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Markus Heidelberg]

Sverre Rabbelier, 05.03.2009:
> Heya,
> 
> On Thu, Mar 5, 2009 at 23:15, Finn Arne Gangstad <finnag@pvv.org> wrote:
> > Previously, git push [remote] with no arguments would behave like
> > "git push <remote> :" if no push refspecs were configured for the remote.
> > It may be too easy for novice users to write "git push" or
> > "git push origin" by accident, so git will now push nothing, and give an
> > error message in such cases.
> 
> Config option please, I very much like the current behavior.

git push --nothing  ? :)

Markus

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Markus Heidelberg]

Markus Heidelberg, 05.03.2009:
> Sverre Rabbelier, 05.03.2009:
> > Heya,
> > 
> > On Thu, Mar 5, 2009 at 23:15, Finn Arne Gangstad <finnag@pvv.org> wrote:
> > > Previously, git push [remote] with no arguments would behave like
> > > "git push <remote> :" if no push refspecs were configured for the remote.
> > > It may be too easy for novice users to write "git push" or
> > > "git push origin" by accident, so git will now push nothing, and give an
> > > error message in such cases.
> > 
> > Config option please, I very much like the current behavior.
> 
> git push --nothing  ? :)

Oh, I confused "config option" with "command line argument"...

Markus

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Sverre Rabbelier]

Heya,

On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> Oh, I confused "config option" with "command line argument"...

Right, I'd like to be able to do:
$ git config push.iamnotretarded true
$ git push

-- 
Cheers,

Sverre Rabbelier

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Junio C Hamano]

If you want to pursue this, you at least need three patches, preferably
four:

 (1) Add a configuration option the existing users can use to ask for
     "with nothing else, please continue to default to matching refs".

     Add a logic to tell "nothing is configured, hence we default to
     matching refs" and "the user explicitly told us either via the
     command line, or in the configuration file to use matching refs"
     cases.  Use the logic to issue a *warning* upon the former case that
     tells the users the following, very loudly:

     - "default to push matching" may be changed in a future version of
       git to "default to push nothing";

     - The user can squelch the warning by various ways:

       - If you want to keep the "matching refs" behaviour, do $this...
       - If you want to have $this behaviour, do $that...
       - ...

     Keep the default for the unconfigured case, after issuing the
     warning, to the matching refs.

 (2) Add a deprecation notice to Documentation/RelNotes-1.6.3.txt similar
     to the way denyCurrentBranch was announced in 1.6.2 release notes (I
     need to carry that part forward to the draft release notes to 1.6.3).

     Mention that these two patches are proposed to be applied immediately.

 (3) Flip the default for unconfigured case to "nothing".  Update the
     warning message you wrote in (1) to explain that:

     - The default used to be "matching refs", but it now is "nothing".
       This message is given loudly because a silent change of default 
       is dangerous to users.

     - The user can squelch the warning by doing ... (I expect the
       instructions will stay the same as in (1)).

     Mention that this patch is proposed to be applied in the next major
     update (perhaps 1.7.0).

 (4) Remove the warning but keep the default to "nothing".  Mention that
     this is to be applied long after (3).

I won't comment on code quality other than hinting that you do not want to
reinvent has_multiple_bits().

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Johannes Schindelin]

Hi,

On Thu, 5 Mar 2009, Sverre Rabbelier wrote:

> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > Oh, I confused "config option" with "command line argument"...
> 
> Right, I'd like to be able to do:
> $ git config push.iamnotretarded true
> $ git push

LOL!  Sverre, you have a way to crack me up...

Snickering,
Dscho

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Junio C Hamano]

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

> On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
>
>> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
>> <markus.heidelberg@web.de> wrote:
>> > Oh, I confused "config option" with "command line argument"...
>> 
>> Right, I'd like to be able to do:
>> $ git config push.iamnotretarded true
>> $ git push
>
> LOL!  Sverre, you have a way to crack me up...

I found it amusing, too.

It may have some correlation with how well organized your work habit is,
but I do not think it has much correlation with being retarded.  It is
more about "'matching refs' is the perfect default for _my_ use pattern,
don't mess with it, please".

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Johannes Schindelin]

Hi,

Disclaimer: if you are offended by constructive criticism, or likely to 
answer with insults to the comments I offer, please stop reading this mail 
now (and please do not answer my mail, either). :-)

Still with me?  Good.  Nice to meet you.

Just for the record: responding to a patch is my strongest way of saying 
that I appreciate your work.

On Thu, 5 Mar 2009, Finn Arne Gangstad wrote:

> Previously, git push [remote] with no arguments would behave like
> "git push <remote> :" if no push refspecs were configured for the remote.
> It may be too easy for novice users to write "git push" or
> "git push origin" by accident, so git will now push nothing, and give an
> error message in such cases.
> 
> Teach git push a new option "--matching" that keeps the old behavior of
> pushing all matching branches when none are configured.

As others have commented, you cannot just go and fsck existing users over.  
That is just not flying well.

IMHO you should always consider the downsides of your patch in addition to 
the upsides, and not only for yourself, but also for others.

> @@ -63,10 +63,11 @@ 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
> +already exists on the remote side. Nothing will be pushed

The two spaces after the full stop were not actually a typo.

>  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).
>  
> +
>  --all::

Please do not change the style of the surrounding text.  We do not have 
double empty lines there.

> diff --git a/builtin-push.c b/builtin-push.c
> index 122fdcf..ffc648d 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -48,6 +48,12 @@ static void set_refspecs(const char **refs, int nr)
>  	}
>  }
>  
> +
> +static int has_multiple_bits(unsigned int x)
> +{
> +	return (x & (x - 1)) != 0;
> +}
> +
>  static int do_push(const char *repo, int flags)

To spare you searching: HAS_MULTI_BITS(x) (it is defined in 
git-compat-util.h).

And by removing your function, you also remove another double empty line.

> @@ -71,17 +77,24 @@ static int do_push(const char *repo, int flags)
>  		return error("--mirror can't be combined with refspecs");
>  	}
>  
> -	if ((flags & (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) ==
> -				(TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) {
> -		return error("--all and --mirror are incompatible");
> +	if (has_multiple_bits(flags & (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR | TRANSPORT_PUSH_MATCHING))) {
> +		return error("--all, --mirror and --matching are incompatible");

These are awfully long lines.  Not so good.

>  	}
>  
> -	if (!refspec
> -		&& !(flags & TRANSPORT_PUSH_ALL)
> -		&& remote->push_refspec_nr) {
> -		refspec = remote->push_refspec;
> -		refspec_nr = remote->push_refspec_nr;
> +	if ((flags & TRANSPORT_PUSH_MATCHING)  && refspec) {
> +		return error("--matching cannot be combined with refspecs");
>  	}
> +
> +

Yet another double empty line.

> +	if (!refspec && !(flags & TRANSPORT_PUSH_ALL)) {
> +		if (remote->push_refspec_nr) {
> +			refspec = remote->push_refspec;
> +			refspec_nr = remote->push_refspec_nr;
> +		} else if (!(flags & TRANSPORT_PUSH_MATCHING)) {
> +			return error("No refspecs given and none configured for %s, nothing to push.", remote->name);
> +		}

Long line and surplus curly brackets.

Just to make it clear, because many people misunderstand my comments: I 
would not have spent my precious time writing this email if I did not 
think that --matching is something we want to have.

Ciao,
Dscho

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Sverre Rabbelier]

Heya,

On Fri, Mar 6, 2009 at 11:32, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
>>> Right, I'd like to be able to do:
>>> $ git config push.iamnotretarded true
>>> $ git push
>>
>> LOL!  Sverre, you have a way to crack me up...

Hehe, good, never hurts to add some humor to this list every now and then ;).

> I found it amusing, too.

I think that humor at times is an effective way to convey your point
while and at the same time keeping the tone light :).

> It may have some correlation with how well organized your work habit is,
> but I do not think it has much correlation with being retarded.  It is
> more about "'matching refs' is the perfect default for _my_ use pattern,
> don't mess with it, please".

For me the reason 'git push' works well for me is that origin is
repo.or.cz and I use the repo there just to synch my changes between
my laptop and my pc (and to keep a backup). I reckon there are other
workflows for which it makes sense to use 'git push' directly :).

-- 
Cheers,

Sverre Rabbelier

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Finn Arne Gangstad]

On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
> >
> >> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
> >> <markus.heidelberg@web.de> wrote:
> >> > Oh, I confused "config option" with "command line argument"...
> >> 
> >> Right, I'd like to be able to do:
> >> $ git config push.iamnotretarded true
> >> $ git push
> >
> > LOL!  Sverre, you have a way to crack me up...
> 
> I found it amusing, too.
> 
> It may have some correlation with how well organized your work habit is,
> but I do not think it has much correlation with being retarded.  It is
> more about "'matching refs' is the perfect default for _my_ use pattern,
> don't mess with it, please".

So here is my current WIP suggestion for a new "push.default"
variable, I am not sure if a single entry can express all useful
choices, or if it is a good idea to introduce more default choices
other than "nothing" (with the goal of making it the default in a
later release).

I think all the values here make sense as a --option to git push
though (except --nothing...)

Suggested new entry in config.txt:

push.default::
	Defines the action git push should take if no refspec is given
	on the command line, no refspec is configured in the branch, 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 set. `origin` is also used if
	you are not on a branch at all.
+
* `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.
* `same-remote` push all matching branches that are configured to use
  the current remote. Branches with no remote configuration are not pushed.
* `tracked` push all branches that are tracking a branch on the current
  remote to their counterpart.


- Finn Arne

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Johannes Schindelin]

Hi,

On Fri, 6 Mar 2009, Finn Arne Gangstad wrote:

> On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
> > >
> > >> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
> > >> <markus.heidelberg@web.de> wrote:
> > >> > Oh, I confused "config option" with "command line argument"...
> > >> 
> > >> Right, I'd like to be able to do:
> > >> $ git config push.iamnotretarded true
> > >> $ git push
> > >
> > > LOL!  Sverre, you have a way to crack me up...
> > 
> > I found it amusing, too.
> > 
> > It may have some correlation with how well organized your work habit is,
> > but I do not think it has much correlation with being retarded.  It is
> > more about "'matching refs' is the perfect default for _my_ use pattern,
> > don't mess with it, please".
> 
> So here is my current WIP suggestion for a new "push.default"
> variable, I am not sure if a single entry can express all useful
> choices, or if it is a good idea to introduce more default choices
> other than "nothing" (with the goal of making it the default in a
> later release).

Speaking of which, Steffen (who cannot reply right now, since he is AFK 
for a while) had a patch to install "remote.<branch>.push = HEAD" with 
clone and remote.  Would that be better?

Ciao,
Dscho

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[John Tapsell]

2009/3/6 Finn Arne Gangstad <finnag@pvv.org>:
> On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
>> >
>> >> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
>> >> <markus.heidelberg@web.de> wrote:
>> >> > Oh, I confused "config option" with "command line argument"...
>> >>
>> >> Right, I'd like to be able to do:
>> >> $ git config push.iamnotretarded true
>> >> $ git push
>> >
>> > LOL!  Sverre, you have a way to crack me up...
>>
>> I found it amusing, too.
>>
>> It may have some correlation with how well organized your work habit is,
>> but I do not think it has much correlation with being retarded.  It is
>> more about "'matching refs' is the perfect default for _my_ use pattern,
>> don't mess with it, please".
>
> So here is my current WIP suggestion for a new "push.default"
> variable, I am not sure if a single entry can express all useful
> choices, or if it is a good idea to introduce more default choices
> other than "nothing" (with the goal of making it the default in a
> later release).
>
> I think all the values here make sense as a --option to git push
> though (except --nothing...)
>
> Suggested new entry in config.txt:
>
> push.default::
>        Defines the action git push should take if no refspec is given
>        on the command line, no refspec is configured in the branch, 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 set. `origin` is also used if
>        you are not on a branch at all.
> +
> * `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.
> * `same-remote` push all matching branches that are configured to use
>  the current remote. Branches with no remote configuration are not pushed.
> * `tracked` push all branches that are tracking a branch on the current
>  remote to their counterpart.

How about 'current', to simply push the current the branch.  It could
even prompt if it's not tracked yet.

Most (all?) other revision control systems have this 'current'
behaviour by default.

John

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Finn Arne Gangstad]

On Fri, Mar 06, 2009 at 01:07:56PM +0100, Johannes Schindelin wrote:
> [...]
> 
> Speaking of which, Steffen (who cannot reply right now, since he is AFK 
> for a while) had a patch to install "remote.<branch>.push = HEAD" with 
> clone and remote.  Would that be better?

Are you referring to the patch he suggested in October 2007? I'm
reading the October/November archives now, and it seems these things
have been discussed before... Ok so re-reading the discussion from
October/November 2007, it seems that we are having exactly the same
discussion again! I did not investigate far enough back in time before
firing up this thread again evidently.

Reading the threads almost makes me sad. Steffen had a lot of great
patches and ideas (implementing --current, adding tests, ...), but it
was somehow dropped. After having read through this it would feel
wrong somehow to even post patches on this topic, since I would
effectively just redo what he already did.

The only difference between his approach and what I am suggesting
seems to be that he mostly wanted "git push" to do various useful
tasks depending on configuration (the remote.<branch>.push stuff),
while I mostly want "git push" to do nothing by default. We both agree
that the current "git push" default behavior is very bad for our
workflow (many developers against one or more shared repos).

- Finn Arne

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Jakub Narebski]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 6 Mar 2009, Finn Arne Gangstad wrote:
>> On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>> On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
>>>>> 
>>>>> Right, I'd like to be able to do:
>>>>> $ git config push.iamnotretarded true
>>>>> $ git push
>>>>
>>>> LOL!  Sverre, you have a way to crack me up...
>>> 
>>> I found it amusing, too.
>>> 
>>> It may have some correlation with how well organized your work habit is,
>>> but I do not think it has much correlation with being retarded.  It is
>>> more about "'matching refs' is the perfect default for _my_ use pattern,
>>> don't mess with it, please".
>> 
>> So here is my current WIP suggestion for a new "push.default"
>> variable, I am not sure if a single entry can express all useful
>> choices, or if it is a good idea to introduce more default choices
>> other than "nothing" (with the goal of making it the default in a
>> later release).
> 
> Speaking of which, Steffen (who cannot reply right now, since he is AFK 
> for a while) had a patch to install "remote.<branch>.push = HEAD" with 
> clone and remote.  Would that be better?

Errr... I thought that "remote.<remotename>.push = HEAD" works?

But note that "remote.<name>.push = HEAD" (push current branch only)
and "remote.<name>.push = :" (push matching branches, i.e. curent
behavior) works only if you have remote configured... "git push <URL>"
won't be affected, and people (probably) would want to either have
'nothing' as default, or/and be able to configure it to nothing,
current, or matching (at least).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Jakub Narebski]

John Tapsell <johnflux@gmail.com> writes:
> 2009/3/6 Finn Arne Gangstad <finnag@pvv.org>:
>> On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>
>>>> On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
>>>>
>>>>> On Thu, Mar 5, 2009 at 23:25, Markus Heidelberg
>>>>> <markus.heidelberg@web.de> wrote:
>>>>>> Oh, I confused "config option" with "command line argument"...
>>>>>
>>>>> Right, I'd like to be able to do:
>>>>> $ git config push.iamnotretarded true
>>>>> $ git push
>>>>
>>>> LOL!  Sverre, you have a way to crack me up...
>>>
>>> I found it amusing, too.
>>>
>>> It may have some correlation with how well organized your work habit is,
>>> but I do not think it has much correlation with being retarded.  It is
>>> more about "'matching refs' is the perfect default for _my_ use pattern,
>>> don't mess with it, please".
>>
>> So here is my current WIP suggestion for a new "push.default"
>> variable, I am not sure if a single entry can express all useful
>> choices, or if it is a good idea to introduce more default choices
>> other than "nothing" (with the goal of making it the default in a
>> later release).
>>
>> I think all the values here make sense as a --option to git push
>> though (except --nothing...)
>>
>> Suggested new entry in config.txt:
>>
>> push.default::
>>        Defines the action git push should take if no refspec is given
>>        on the command line, no refspec is configured in the branch, 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 set. `origin` is also used if
>>        you are not on a branch at all.
>> +
>> * `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.
>> * `same-remote` push all matching branches that are configured to use
>>  the current remote. Branches with no remote configuration are not pushed.
>> * `tracked` push all branches that are tracking a branch on the current
>>  remote to their counterpart.
> 
> How about 'current', to simply push the current the branch.  It could
> even prompt if it's not tracked yet.

Note that if you have configuration for <remote>, you can simply add
"remote.<remote>.push = HEAD" for pushing current branch only, and
"remote.<remote>.push = :" for current matching behavior.  Perhaps
"remote.<remote>.push = " works for push nothing?
 
> Most (all?) other revision control systems have this 'current'
> behaviour by default.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
>> Speaking of which, Steffen (who cannot reply right now, since he is AFK 
>> for a while) had a patch to install "remote.<branch>.push = HEAD" with 
>> clone and remote.  Would that be better?
>
> Errr... I thought that "remote.<remotename>.push = HEAD" works?
>
> But note that "remote.<name>.push = HEAD" (push current branch only)
> and "remote.<name>.push = :" (push matching branches, i.e. curent
> behavior) works only if you have remote configured... "git push <URL>"
> won't be affected, and people (probably) would want to either have
> 'nothing' as default, or/and be able to configure it to nothing,
> current, or matching (at least).

When you and Dscho contradict with each other, I seem to end up agreeing
with Dscho most of the time, but for this particular one, I completely
agree with you.

I personally think Finn's suggested list is overengineered, and we should
start with only three: "nothing", "current" (aka HEAD), and "matching".
It is Ok to have a separate discussion to figure out what other default
behaviours are desireable, but I think that should come after the dust
settled from the transition, and more importantly, I think the other kinds
of fine-tuned behaviour needs to be per-remote, and is not something the
repository (or user) wide default push.default can cover.

In addition to your counterargument, clone to set up remote.*.push is
introducing an inconsistency between existing and new repositories until
the default is changed for everybody, and the recent trend is to avoid
that kind of inconsistency.  Steffen's patch _could_ use push.default to
infer what kind of remote.*.push to set up when adding a remote (or when
cloning, if you take push.default from $HOME/.gitconfig), but at that
point it becomes a redundant information.

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Johannes Schindelin]

Hi,

On Fri, 6 Mar 2009, Jakub Narebski wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > On Fri, 6 Mar 2009, Finn Arne Gangstad wrote:
> >> On Fri, Mar 06, 2009 at 02:32:53AM -0800, Junio C Hamano wrote:
> >>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >>>> On Thu, 5 Mar 2009, Sverre Rabbelier wrote:
> >>>>> 
> >>>>> Right, I'd like to be able to do:
> >>>>> $ git config push.iamnotretarded true
> >>>>> $ git push
> >>>>
> >>>> LOL!  Sverre, you have a way to crack me up...
> >>> 
> >>> I found it amusing, too.
> >>> 
> >>> It may have some correlation with how well organized your work habit is,
> >>> but I do not think it has much correlation with being retarded.  It is
> >>> more about "'matching refs' is the perfect default for _my_ use pattern,
> >>> don't mess with it, please".
> >> 
> >> So here is my current WIP suggestion for a new "push.default"
> >> variable, I am not sure if a single entry can express all useful
> >> choices, or if it is a good idea to introduce more default choices
> >> other than "nothing" (with the goal of making it the default in a
> >> later release).
> > 
> > Speaking of which, Steffen (who cannot reply right now, since he is AFK 
> > for a while) had a patch to install "remote.<branch>.push = HEAD" with 
> > clone and remote.  Would that be better?
> 
> Errr... I thought that "remote.<remotename>.push = HEAD" works?
> 
> But note that "remote.<name>.push = HEAD" (push current branch only)
> and "remote.<name>.push = :" (push matching branches, i.e. curent
> behavior) works only if you have remote configured... "git push <URL>"
> won't be affected, and people (probably) would want to either have
> 'nothing' as default, or/and be able to configure it to nothing,
> current, or matching (at least).

The question was not if remote.<remote>.push = HEAD works, but if it is 
installed by default.

Ciao,
Dscho

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Johannes Schindelin]

Hi,

On Fri, 6 Mar 2009, Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > ...
> >> Speaking of which, Steffen (who cannot reply right now, since he is 
> >> AFK for a while) had a patch to install "remote.<branch>.push = HEAD" 
> >> with clone and remote.  Would that be better?
> >
> > Errr... I thought that "remote.<remotename>.push = HEAD" works?
> >
> > But note that "remote.<name>.push = HEAD" (push current branch only) 
> > and "remote.<name>.push = :" (push matching branches, i.e. curent 
> > behavior) works only if you have remote configured... "git push <URL>" 
> > won't be affected, and people (probably) would want to either have 
> > 'nothing' as default, or/and be able to configure it to nothing, 
> > current, or matching (at least).
> 
> When you and Dscho contradict with each other, I seem to end up agreeing 
> with Dscho most of the time, but for this particular one, I completely 
> agree with you.

A word of caution.  Quite a few people (or at least a few people who write 
loud-enough emails) do not like me.  So even if you agree with my 
reasoning, you might want to point out that you are not agreeing with 
"Dscho", but rather mention that you happened to agree with a particular 
line of argument.

Certain people might mistake your being convinced by arguments for pure 
politics otherwise.

> I personally think Finn's suggested list is overengineered, and we 
> should start with only three: "nothing", "current" (aka HEAD), and 
> "matching". It is Ok to have a separate discussion to figure out what 
> other default behaviours are desireable, but I think that should come 
> after the dust settled from the transition, and more importantly, I 
> think the other kinds of fine-tuned behaviour needs to be per-remote, 
> and is not something the repository (or user) wide default push.default 
> can cover.

As long as the default does not change without warning, I am sure we are 
safe there.

Me mentioning Steffen's patch was more meant to kickstart people who 
missed the discussion into the intricacies, not to say that one or the 
other default makes most sense.

Personally, I am torn between the current default, which appears massively 
reasonable to me (probably due to being exposed to Git for quite some 
time), but I can also see why Steffen's approach appeals to some people.

Ciao,
Dscho

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Markus Heidelberg]

Johannes Schindelin, 06.03.2009:
> > -already exists on the remote side.  This is the default operation mode
> > +already exists on the remote side. Nothing will be pushed
> 
> The two spaces after the full stop were not actually a typo.

What's its purpose? Just recently I added "set nojoinspaces" to my
.vimrc to not insert two spaces when joining sentences.

Markus

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Johannes Schindelin]

Hi,

On Mon, 9 Mar 2009, Markus Heidelberg wrote:

> Johannes Schindelin, 06.03.2009:
> > > -already exists on the remote side.  This is the default operation mode
> > > +already exists on the remote side. Nothing will be pushed
> > 
> > The two spaces after the full stop were not actually a typo.
> 
> What's its purpose? Just recently I added "set nojoinspaces" to my
> .vimrc to not insert two spaces when joining sentences.

It was explained to me as "English grammar".  Two spaces after a full 
stop.

Ciao,
Dscho

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Markus Heidelberg]

Johannes Schindelin, 09.03.2009:
> Hi,
> 
> On Mon, 9 Mar 2009, Markus Heidelberg wrote:
> 
> > Johannes Schindelin, 06.03.2009:
> > > > -already exists on the remote side.  This is the default operation mode
> > > > +already exists on the remote side. Nothing will be pushed
> > > 
> > > The two spaces after the full stop were not actually a typo.
> > 
> > What's its purpose? Just recently I added "set nojoinspaces" to my
> > .vimrc to not insert two spaces when joining sentences.
> 
> It was explained to me as "English grammar".  Two spaces after a full 
> stop.

I should have tried searching, I didn't think I'd get useful results
with "two spaces after sentence" as search item, but I did.

http://en.wikipedia.org/wiki/Full_stop#Spacing_after_full_stop

Two spaces between sentences.  But no space between
text and the dash---strange.

Markus

Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

[Jeff King]

On Mon, Mar 09, 2009 at 09:48:31PM +0100, Johannes Schindelin wrote:

> > > The two spaces after the full stop were not actually a typo.
> > 
> > What's its purpose? Just recently I added "set nojoinspaces" to my
> > .vimrc to not insert two spaces when joining sentences.
> 
> It was explained to me as "English grammar".  Two spaces after a full 
> stop.

It's not grammar, but rather a typographical convention dating to
monospaced print fonts. It's mostly outdated these days for computer
input, as markup languages will put in the "right" amount of space
automatically (e.g., one and two spaces after a period are equivalent in
both TeX and HTML) and proportional fonts and justification mean your
spacing isn't standard, anyway. So as a rule, it seems to be dying out.
You can google "two spaces after period" to see the ensuing flamewars.

In this particular instance, we consider the pre-markup version
something readable (since that is the point of asciidoc), and people
will tend to view it in a monospaced fonts. So it at least makes a
difference here (and you can then have a flamewar about how it looks).

-Peff