Jonathan Nieder <jrnieder@xxxxxxxxx> 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 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. 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 idea. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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