Jonathan Nieder <jrnie...@gmail.com> writes:
> When push.default is set to 'matching', git will push local branches
> to remote branches that already exist with the same (matching) name.
Yes, that's better than the original patch (and remains two lines).
>>>>> + "In Git 2.0 the new push.default of 'simple' will push only the
>>>>> + "branch to the same remote branch used by git pull. A push will\n"
>>>>> + "only succeed if the remote and local branches have the same name.\n"
>>> while you can see that it is not telling a lie if you read it twice,
>>> "will only succeed if" feels somewhat roundabout.
>>> ... push only the current branch back to the branch of the
>>> same name, but only if 'git pull' is set to pull from that
>>> branch. Otherwise the push will fail.
>>> might be an improvement, but I dunno.
>> I do not see much difference actually. I tend to prefer the original
>> version: to me the expected behavior is to make push and pull
>> essentially symetrical, and the fact that it fails if the branch is
>> named differently is a safety feature comming on top of that.
> In Git 2.0 (or now, if push.default is set to 'simple'), git will behave
> more conservatively by pushing only the current branch to the
> remote branch used by "git pull", and only if the remote and local
> have the same name.
I prefered the original, as it had two sentences. Reading only the first
one gave the important information.
> In Git 2.0, git will default to a more conservative 'simple' behavior
> that only pushes the current branch.
That's an option too, but I think mentionning "git pull" was a good
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html