Re: [RFC/PATCH] push: introduce implicit push

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Apr 16, 2013, 02:05 UTC
Message-ID: <20130416020515.GE3262@elie.Belkin>
In-Reply-To: <CALkWK0nNn_dGgr8F-kcQZm9UfkZAKwBd0bPSW9yCex4L9F+4Qw@mail.gmail.com>

Ramkumar Ramachandra wrote:

> Junio C Hamano wrote:

Show 6 quoted lines

>> That "changing the meaning of <name>" in the middle, and doing so
>> will be confusing to the users, is exactly the issue, isn't it?
>
> Yes, but we have to change _something_ if we don't want to hit a WTF
> like 'git push master next' pushing master and next to
> branch.<HEAD>.pushremote.

Yep. In the usual case, all relevant remotes are "origin" anyway, so there's no confusion. In the confusing cases it would be safer to error out and give the user a hint about how to make the configuration less confusing.

The manual could say:

	In olden times, each [branch "<name>"] section would often have
	its own remote and pushRemote settings.  Ordinary branch creation
	even created such a configuration.  Nowadays that is
	discouraged: we have found that it is less confusing in
	practice to:

	 A) Typically fetch from one remote "[remote] default = origin"
	    and push to another "[remote] pushDefault = personal".

	 B) In atypical cases, explicitly name the remote being used
	    on the command line.

Thinking more, I suspect there is an asymmetry between "fetch" and "push" here that we missed. The manual could say:

	In typical usage, a person ordinarily pushes to a single
	preferred publication point.  You can set your publication
	point using the "[remote] pushDefault" setting:

		[remote]
			pushDefault = myserver.example.com:/path/to/repo.git

	To push a collection of branches to that remote repository,
	pass a list of branch names to "git push" with a
	disambiguating "--" to ensure the first branch name is not
	treated as a remote name:

		git push -- master next pu

	For historical reasons, if "[remote] pushDefault" is not set,
	it defaults to the remote that the branch being pushed is set
	to pull from (its "upstream").  If pushDefault is unset and
	multiple branches being pushed have different upstream
	repositories, Git will error out to allow you to disambiguate.

	To push to a different remote repository, just name it
	explicitly on the command line.

		git push korg -- master next pu

The asymmetry is because a command like "git fetch -- master next pu" doesn't make much sense, since you have to know what remote you fetched from to act on the fetch result.

As you hinted before, this would involve reverting the introduction of "branch.<name>.pushremote", with the explanation that it was a mistake inspired by that false symmetry, that you noticed and were uncomfortable with but the rest of us were blind too.

Does that make sense?

Jonathan