Re: [PATCH] Documentation: add a planning document for the next CLI revamp

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 4, 2008, 00:44 UTC
Message-ID: <7vljw0tj49.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20081104000207.GA29458@artemis.corp>

Pierre Habouzit <madcoder@debian.org> writes:

Show 9 quoted lines

>> Ok, I agree that may be a problem.
>> 
>> But that would not change if you only changed the default behaviour from
>> matching to _this branch_.  You need to also teach a new mode of operation
>> to send-pack/receive-pack pair, which is to "update the same branch as the
>> one I am on locally, but do not do anything if there is no such branch
>> over there".  I do not think we have such a mode of operation currently.
>
> You're right.

Perhaps "git push --no-create"?

In hindsight, _if_ we did not have to worry about backward compatibility at all, I might agree that the way "git push" ought to work with least surprise would be:

 * "git push" is the same as "git push origin" (override 'origin' with
   branch.$current_branch.remote);

 * "git push $remote" is the same as "git push --no-create $remote HEAD"
   (override 'HEAD' with remote.$remote.push);

 * "git push $remote $any_non_empty_refspec" does what it is told without
   configuration interfering.

Current behaviour satisfies the first one and the third one. Instead of the second, the current behaviour is:

 * "git push $remote" is the same as "git push $remote :" (override ':'
   with remote.$remote.push).

Show 5 quoted lines

>> By the way, didn't we add a feature to let you say "git push $there :"
>> which is to do what "git push --matching $there" would do?
>
> I don't know, I thought git push --matching $remote would be the same as
> git push $remote ?

I think the point of "push --matching" (or an explicit "push $there :") is so that you can defeat what you configured. For example, you could have:

	[branch "master"]
        	remote = gitster
	[remote "gitster"]
        	url = gitster:/pub/git/git.git/
                push = HEAD

And with such a configuration, "git push" or "git push gitster" would only push to the current branch.

You can countermand with "push gitster master next", of course, but you would need a way to ask for the matching from the command line without listing all the names, hence you would say "push gitster :".

I think you meant to give the --matching option the same efffect. My comment is that you do not need a new option, as we already have that feature.