Re: [RFC - draft] List of proposed future changes that are backward incompatible
- From
- david@lang.hm <david@lang.hm>
- Date
- Feb 16, 2009, 15:33 UTC
- Message-ID
- <alpine.DEB.1.10.0902160731420.14911@asgard.lang.hm>
- In-Reply-To
- <alpine.DEB.1.00.0902161121290.10279@pacific.mpi-cbg.de>
On Mon, 16 Feb 2009, Johannes Schindelin wrote:
Show 15 quoted lines
> On Sun, 15 Feb 2009, david@lang.hm wrote: > >> please be careful with the term 'deprecated', just becouse you would do >> something a different way doesn't make it 'deprecated', that term should >> only be used for features that are on their way out of the product, but >> haven't been removed yet. > > It is not deprecated because I do not like it. Actually, I am pretty > indifferent about the pushing into a non-bare repository. > > It is deprecated because a lot of people active in the Git community spend > a real lot of time explaining to a whole bunch of new users on IRC and > recently even on this list why their pushing into a non-bare repository > does not work, and why their suggestions how to solve the issue does not > work either.
if it is the correct thing to do with some workloads, it's not being deprecated. if it was deprecated then it is a capability that would be scheduled for complete removal, and nobody should ever use. not just the case where it needs to be used carefully, and you are putting in a warning about it.
David Lang