On Monday, January 16, 2012 04:33:00 pm Junio C Hamano wrote: > With your suggestion, they need to export > "GIT_MERGE_EDIT=0" today, and they will need to update > again to export "GIT_MERGE_SOMETHINGELSE=0" when such an > incompatible change comes. > > With a single "GIT_MERGE_LEGACY=YesPlease", they can be > future-proofed today and will not be affected when we > make another incompatible change. > > So I am not sure why separating the big-red-switch into > smaller pieces would be an improvement, especially wnen > the scripts that want to specify finer-grained control > of features can use "--[no-]edit" options to explicitly > ask for it. Then, what would I do if I write a script which uses the new edit functionality (without even being aware that there was an old way) and you introduce a new incompatibility? I can't turn on GIT_MERGE_LEGACY then since it would revert to behavior which my script would not expect (since it was written after the current incompatibility, but before the new one)! -Martin -- 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