Junio C Hamano <gits...@pobox.com> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html