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

From: Jeff King <peff@peff.net>
Date: Mar 13, 2012, 21:30 UTC
Message-ID: <20120313213045.GD27436@sigill.intra.peff.net>
In-Reply-To: <7vfwddskon.fsf@alter.siamese.dyndns.org>

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

Show 12 quoted lines

> 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.

Show 6 quoted lines

> > 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.

Show 8 quoted lines

> 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.

Show 6 quoted lines

> 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