Pete Harlan <pgit@xxxxxxxxxxxx> writes: > ... The > only time I think I'd prefer "LEGACY" is if you're planning on > deprecating and removing it eventually and you want to indicate > something to that effect in the name. The discussion that led to the naming of that LEGACY token needs to be re-read, then. The kind of "LEGACY" you prefer is exactly why the environment variable is called LEGACY in the patch you are commenting on, written in response to Linus's suggestion to switch the default, even though I am not 100% buying it. Having said that, I think I am wasting my time responding to this thread during the feature-freeze period for v1.7.9, as I am not a big fan of switching the default without adequate warning and transition plans, after getting burned by the "'git-foo' vs 'git foo'" flames back in the v1.6.0 release. We would likely to take a gradual and smoother migration route to transition, e.g. v1.7.9 to introduce "merge --edit", v1.7.10 to introduce a configuration variable merge.edit (lack of which gives a warning and an advice message while defaulting to 'no' to preserve the traditional behaviour), and finally v1.8.0 (or v2.0) to flip the default to 'yes' (while the configuration still giving a warning and an advice message) that "merge --no-edit" can still countermand. So you have until v1.7.10 to decide a good name for the overriding environment variable. -- 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