Pierre Habouzit <madcoder@xxxxxxxxxx> writes:
>> 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).
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
