On Thu, Mar 12, 2020 at 2:27 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Jeff King <peff@xxxxxxxx> writes: > > > Though in this particular case, I don't mind too much just leaving "am" > > as an alias for "apply" (it was actually the first thing I tried when > > writing my earlier emails, but I'm probably not a representative user > > there). Putting that in a release, though, may mean supporting it > > forever. :) > > Yeah, I agree that what used to exist only in 'next' and we chose to > remove it before it its 'master', does not deserve to be supported > forever. 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 ;-) > > > I guess like your email I'm going back and forth between the two > > options. I think that means it probably doesn't matter _too_ much either > > way. > > OK, let's avoid screwing it up even further by doing no more damage > than merging just the three fix-ups we discussed recently. > > The fact that jrnieder runs 'next'+patches for his $DAYJOB users > makes me hope that there may be other organizations that do the > same, and cooking in 'next' would mean somthing, though. > > 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? I agree, it's super cool that Emily and Jonathan distribute 'next' to their users at Google and provide us lots of early feedback. I wish we had something similar; currently, the only control I have is requesting that some documentation file that includes a recommended minimum git version be bumped to something newer, and I usually need to provide a reason (I can't just say, "It's the newest release"). Other than that, developers install whatever version of git they like, possibly unaware of what's in that documentation file. In fact, not having a way to control git versions is leading to discussions of spending my time to not only fix issues in git (e.g. the read-tree -mu HEAD problems with sparse-checkout) but also writing some separate program that does that piece independent of git so that we can work with a variety of git versions. Such a pain...does anyone know how to educate me to advocate to the company that we come up with some more controlled git version?
