Re: [RFC PATCH] push: start warning upcoming default change for push.default

[Jeff King <peff@peff.net>]

On Mon, Mar 12, 2012 at 12:06:48PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > ... This is not a push.default issue,
> > but I think it is somewhat related, and maybe worth discussing along
> > with the topic of asymmetry. ...
> > I've mostly trained my fingers to type "git push
> > <my-publish-repo>", but I do occasionally forget.
> 
> In an assymmetric set-up, you would typically push into one place
> but update from one or more places, so it might make sense to make
> it easier to say "git push" and "git pull $there".  But that does
> not solve the fundamental issue, I would think.

I think it can even be a bit more complex than that. For example, I
actually _never_ run git-pull. Instead, I fetch, and then use the
upstream config for lots of other operations, like seeing what's in a
topic branch, rebasing, etc.

So to me, it is not just about "symmetry between push and pull", but
that the upstream config is fundamentally about "what is this work based
off of", which may or may not have anything to do with where you are
pushing to.

> > Do other people with
> > asymmetric workflows find this annoying? Do they not care? Or are many
> > fewer people doing asymmetric things than I think?
> 
> I think it is not "they do not care", but "they do not have a good
> solution".  I do not think of anything offhand, either.

The branch.*.pushRemote you mentioned would help with that. But for me,
I would much rather have simply push.defaultRemote. Configuring each
branch independently would be a pain, and I always want to push to my
publishing point (or at least, by default; anything else is a one-off
that can get an option on the command line). It is not a per-branch
thing at all for me.

Speaking of which, I often get annoyed at the per-branch
auto-configuration of upstreams. For example, I find myself doing this:

  [get an idea, read a bug report on the list, etc]
  $ cd git
  $ hack hack hack
  [oh, this is turning into something real. Let's make a branch]
  $ git checkout -b jk/bug-fix
  $ git commit -m 'fix bug'

but now my bug-fix branch is based off of wherever I was (which is
usually some private topic-integration branch I run most of the time).
I wish there was some way to say "No, branches should _always_ consider
origin/master as their upstream, unless I configure them some other
way" (which I do occasionally for building sub-topics on other topics).

Which makes me wonder if perhaps people are using "upstream" to mean
several different thing. I use it to say "this is the branch that this
topic is based off of", which makes "git log @{u}.." helpful, "git
rebase -i" just work, and gives some meaning to the ahead/behind message
(it shows how my topic relates to the main project).

But I think people also use upstream to mean "this is the definitive
version of this branch in some central repo". So they would say that
"jk/bug-fix" is based on "origin/jk/bug-fix". And the ahead/behind
message is about "do I have any local work that needs pushed, or any
remote work that needs pulled?"

And I wonder if this is where some of the debate for
push.default=upstream comes from. Whether that is useful to you or not
would depend on how you set up your branches. In the latter model, I
would think pushing to the upstream would be the right thing.

> Because "upstream" is meant to be "For the branch I am on, you know
> how the branches map between the remote repository, so you already
> know what the right thing to do---do it" mode, the correct "guess"
> in your case is to error out and say "Nah, you are not talking with
> your upstream, so I do not have any clue what branches you want to
> push out and how. As you said that the push.default is upstream, not
> matching, I refuse to even do the matching push in your case.  This
> is an error. Be more specific".

Yeah, I agree that is the only sane thing to do.

> I do not think "the most number of people" is a high-priority issue,
> but "least damage" default may not be necessarily the best.
> 
> Obviously, "nothing" is the least-damage option, and looking at how
> even people on this list cannot decide between current and upstream,
> I actually am very tempted to suggest it as the new default.

I was tempted to suggest that, but it somehow feels too overboard and
unfriendly.  I really like "current", as it seems like the simplest and
unsurprising thing we can do, short of doing nothing at all.

-Peff