Junio C Hamano <gitster@xxxxxxxxx> writes: > I myself thought that replacing the established work process of > these people to the one that instead uses "git config" should be > simple enough even back then, and in the longer term, these old > mechanisms will become disused so that we can remove them, but > deciding _when_ is the good time is not a no-brainer at all. I do not fundamentally have a strong objection against deprecation of these older mechanisms, if the removal is aimed to coincide with a major version bump, like Git 2.0. It however needs to be very well advertised, with clear instruction to help migrate people's workflow and scripts to the mechanism that will survive the purge (i.e. "git config"). We do not want to repeat the "We have advertised that 'git-foo' will stop working at v1.6.0 for 6 months since v1.5.4 release notes, but people complained loudly only after it happend." fiasco again for something "minor" like this. I say "minor" only because I think the cost of keeping these old mechanisms alive is very low (if it is a heavy burden on the maintenance, please tell me and how). So from my point of view, a proposal to remove them has an almost no benefit vs potentially very high cost of having to break many people who are silently happily using them; not a very good benefit/cost ratio. -- 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