Thread (1 message) 1 message, 1 author, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:45:36

Pierre Habouzit [off-list ref] writes:
quoted
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).
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help