All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Keeping <john@keeping.me.uk>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Johannes Sixt <j.sixt@viscovery.net>,
	Git List <git@vger.kernel.org>, Jeff King <peff@peff.net>,
	Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [RFC/PATCH] push: introduce implicit push
Date: Mon, 15 Apr 2013 10:46:05 +0100	[thread overview]
Message-ID: <20130415094605.GD2278@serenity.lan> (raw)
In-Reply-To: <CALkWK0kzpgucLbe5TtwbZ0st51+9ZW2hkML4=yHV4y--USfynA@mail.gmail.com>

On Mon, Apr 15, 2013 at 02:47:35PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > I may be an atypical user, but my expectation currently is that
> > branch.<name>.remote is what is used when I run "git push" with no
> > additional arguments.
> >
> > This is probably because whenever I add additional arguments (currently)
> > I have to specify where I am pushing to.
> >
> > So I think breaking user expectations is a red herring here because the
> > current behaviour means that users cannot have any expectation of what
> > will happen in this case.  Either you don't say anything and "git push"
> > DTRT for your current branch or you must specify precisely what you want
> > to happen (or at least the remote to use if you have push.default =
> > matching or remote.<name>.mirror set).
> >
> > Personally I'd vote for "git push -- master" pushing to
> > remote.pushdefault, but I really don't know how you handle "git push --"
> > with the naïve implementation of that - is it the same as "git push" or
> > "git push $(git config remote.pushdefault)"?
> 
> We're not changing, or even discussing, what a plain git push without
> destination or refspecs specified should do (yes, that means git push
> -- too); it depends on push.default, which already exists.  My
> proposal does not aim to change the current behavior of _any_ current
> invocation (that means git push, git push origin master, git push next
> master v1.2, and so on). It aims to make the new syntax git push
> master +next behave logically.  I think we can all agree that the
> logical solution (leaving aside founded/ unfounded user expectations)
> is to pick destinations for each of the branches specified
> individually.  As I explained in my last email, using
> remote.pushdefault is Wrong because it treats branches like tags, and
> invents a new precedence.  Voting without a basis is useless: do you
> have a counter-argument for the points I raised as to why it is Wrong?

As Junio says in his parallel message, there are different opinions
here, my suggestions was to effectively replace "--" with the value of
remote.pushdefault.  I don't think your solution is not logical, but I
don't think it is the unique logical solution.

The problem is that people have different opinions of what the current
situation means, resulting in different expectations of what push
without a remote should do.  Whatever behaviour we choose /will/ be
surprising to some users, even though it is completely logical.  That
much is clear from the differing opinions in this thread.

  reply	other threads:[~2013-04-15  9:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-12 15:33 [RFC/PATCH] push: introduce implicit push Ramkumar Ramachandra
2013-04-12 22:28 ` Junio C Hamano
2013-04-13  4:49   ` Ramkumar Ramachandra
2013-04-14  4:42     ` Junio C Hamano
2013-04-14  8:33       ` Jakub Narębski
2013-04-14 13:29       ` Ramkumar Ramachandra
2013-04-15  3:04         ` Junio C Hamano
2013-04-15  7:07           ` Johannes Sixt
2013-04-15  7:20             ` Junio C Hamano
2013-04-15  8:35               ` John Keeping
2013-04-15  9:17                 ` Ramkumar Ramachandra
2013-04-15  9:46                   ` John Keeping [this message]
2013-04-15  9:29                 ` Junio C Hamano
2013-04-15  9:44                   ` Ramkumar Ramachandra
2013-04-15  9:59                   ` John Keeping
2013-04-15 16:39                     ` Felipe Contreras
2013-04-15 17:13                       ` John Keeping
2013-04-15 17:18                         ` Felipe Contreras
2013-04-15  9:35           ` Ramkumar Ramachandra
2013-04-16  2:05             ` Jonathan Nieder
2013-04-16  2:13               ` Jonathan Nieder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130415094605.GD2278@serenity.lan \
    --to=john@keeping.me.uk \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j.sixt@viscovery.net \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.