Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

[Jakub Narebski <jnareb@gmail.com>]

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> Brief recap, to check if I understand things correctly:
>>
>> 1. If you use "matching" more often, then it should be enough
>>    to provide remote.<remotename>.push with refspec or wildcard
>>    refspec. 
> 
> Eh, excuse me, what refspec would you write there?  "matching"
> is defined to push the intersection of what we have and what
> they have when "git-push" is run.  I do not think there is any
> way to write that in remote.$there.push and cast in stone.
[...]
>>    Question: what to do if there is no remote.<remotename>.push?
>>    Assume 1-1 matching?
> 
> One-to-one is what 'matching' does, and the way to trigger it is
> not to have a remote.$there.push.

I'm sorry, I had to have "stupid" moment. Thanks a lot for complete 
explanation of git-push, anyway.


>>    ... If one wants to push only current branch, one
>>    would use "git push --current" or "git push <remotename> HEAD".
> 
> I think that is the proposal by Steffen (added back CC).
> 
> I am wondering if an alternative approach could be simpler.  If
> we teach "git-push" to notice when only the refspecs are given
> without remotename, and default to branch.$current.remote in
> such a case, 

Including default remote when branch.<branchname>.remote is not set?

> IOW, make these: 
> 
> 	$ git push HEAD
>       $ git push next
> 
> push the obvious thing to the default remote, I _think_ we can
> achieve the same effect as --current and a bit more.

The only problem would be when there is conflict between remote name and 
branch name (for example default "origin" remote, and old git 
no-separate-remotes "origin" branch, or origin = origin/HEAD).
Perhaps we can reuse '--' as separator between remote(s) and refspecs 
(branch names); other command use it to separate refname / commit-ish 
from pathspec (file name).

So for scripts it would be "git push -- HEAD"; still shorter than
"git push --current".


BTW. what would happen for "git push branch1 branch2" if branch1 has 
different remote than branch2?

> The latter could be run after I made the 'next' integration
> branch into a good shape, switched to 'pu' to merge up other
> bits but before finishing that merging yet (it would not help me
> personally as I do not work that way --- I push things out only
> after I am done with all the public branches --- but it may help
> the others). 

-- 
Jakub Narebski
Poland