Junio C Hamano <gitster@xxxxxxxxx> writes: > I am not sure who this wants to help. The target is for people who may use different versions of Git (e.g. several installed git on the same machine, several machine, or worse, several machines with a shared $HOME/.gitconfig). This includes me. For these people, setting push.default=simple is basically impossible since Git errors out when encountering such setting (it's not ignored, it really makes Git die). > For people who want to anticipate the future, using anything but > 'simple' is not living in the future and waiting for an additional > pain coming from the differences between current and simple. If > current and simple are similar enough that their differences do not > matter, why wait for simple to be available everywhere and switch the > default to it, instead of using current as the default in the first > place? 'simple' is an improvement over 'current' as a default, especially for beginners, but 'current' is already reasonably good. So, the long term goal is really to switch to 'simple', but people who use different versions of Git won't be able to use it before a few years. These people have several options: 1) Keep push.default unset. This is not acceptable because they don't want the big fat warning each time they push. 2) Set push.default to 'matching', to keep the old behavior and squelsh the warning. If they go this way, they will never see the default change. 3) Set push.default to 'current', in which case they have the same behavior as 'simple', except for the safety feature of 'simple' (refuse to push when the name doesn't match the upstream). They can't expect anything better anyway since they are sometimes using a machine which doesn't support 'simple' anyway. To me, option 3) clearly seems to be the best option. I don't understand whether you would advise 1), 2), or maybe a 4) that I would have missed. -- 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