Junio C Hamano wrote: > So let's scrap the "am is taken as a synonym for apply". > It would not help the old version taken from 'next' grok a new > configuration file that uses "apply" anyway ;-) Agreed. For 2.26.0, I'm happy with either - what we currently have, where it defaults to 'merge', or - the more conservative approach where it supports 'merge' but defaults to 'apply' Accepting multiple values for forward compatibility is an optional cherry on top: I would like us to eventually get there, but I don't mind if it doesn't make 2.26.0, and it's probably better to give a change like that some cooking time. (Although I won't complain if it does make 2.26.0. ;-)) [...] > We may want to think of a way to strongly encourage those who are in > charge of choosing and maintaining the versions of Git that is used > in their organization, whose operation depends on the healthy future > versions of Git, to run 'next' or at least 'master', to stay ahead > of the released versions. Some education and advocacy is needed? It's possible we should write up some best practices somewhere in Documentation/ about how to make running "next" go smoothly: - have a responsive infrastructure team. Pay attention to changes landing upstream and have the infra team test before the rest of your user population :) - if you have a large user population, use gradual rollouts so that a subset of users can find problematic changes before they affect everyone - fast rollbacks - telemetry to catch regressions (in latency, for example) when people are too shy to report them We can also advertise places, such as Debian experimental, that people can get snapshots without maintaining them themselves. Thanks, Jonathan
