Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

Johannes Schindelin [off-list ref] writes:

On Mon, 25 Aug 2008, David Woodhouse wrote:

quoted

On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote:

quoted

There is one alternative, and one augmentation:

 (A) We do not do anything.

 (B) In addition to the main transition plan, outside git, prepare an
     optional "git-old-style" package that installs many "git-foo" 
     wrappers in $PATH (i.e. /usr/bin).  Each of them exec "git foo". 
     People who like the dashed form can keep typing "git-foo", even 
     though that will cost them two exec()s.

  (C) Just don't do it. Leave the git-foo commands as they were. They
      weren't actually hurting anyone, and you don't actually _gain_
      anything by removing them.

Umm.  What exactly makes you feel you should ignore the discussions we had 
around the issues on the git and msysgit mailing list?

Well, this was partly my fault, as I did not make it clear in this part
that beating the horse that has been dead for two years is not a
productive way to spend out time.  I however did, in the part David did
not quote, try to make it clear:

  That's all history now anyway.  We should try to do better the next time,
  which is much more important, and that is the topic of this message.

  Now, we haven't set the timeframe yet, but the original plan, advocated by
  Linus and others, was to eventually stop installing "git-foo" form on the
  filesystem for builtin commands.  If we were to do this, we should plan
  how the deprecation period for this change should look like.  I think the
  sequence of events would look like this:

that we are now talking about what we can do better from here going
forward, but these paragraphs were separated from the quoted part that
describes what kind of *variations* are possible in addition to the "the
sequence of events would look like this:" list, and allowed David to make
an out of context quoting that made a comment on an offtopic tangent look
as if it were one of the valid alternatives.