Matthieu Moy wrote:
> Junio C Hamano <gits...@pobox.com> writes:
>> Specifically:
>>
>>>> + "When push.default is set to 'matching', git will push all local
>>>> branches\n"
>>>> + "to the remote branches with the same (matching) name.
>>
>> invites those who do not read documentation to mistake it with using
>> an explicit "refs/heads/*:refs/heads/*" refspec.
>
> Yes, but those who want to know the exact behavior should read the doc.
> That's life.
Surely we can do better?
For example:
When push.default is set to 'matching', git will push local branches
to remote branches that already exist with the same (matching) name.
>>>> + "In Git 2.0 the new push.default of 'simple' will push only the
>>>> current\n"
>>>> + "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.
Perhaps:
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
corresponding
remote branch used by "git pull", and only if the remote and local
branches
have the same name.
Except that forgets the exception having to do with triangular
workflows. So maybe:
In Git 2.0, git will default to a more conservative 'simple' behavior
that only pushes the current branch.
Hope that helps,
Jonathan
--
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
