Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required

Nanako Shiraishi [off-list ref] writes:

Quoting Junio C Hamano [off-list ref]

quoted

Come back with a proof that there has never existed any script that uses
"read-tree" without arguments to purge the index, and I'd immediately
accept and apply the patch to retroactively forbid what the implementation
has allowed users to do for a long time.

For what it's worth, I compiled the very first version of git

 commit e83c5163316f89bfbde7d9ab23ca2e25604af290
 Author: Linus Torvalds [off-list ref]
 Date:   Thu Apr 7 15:13:13 2005 -0700

     Initial revision of "git", the information manager from hell

and its read-tree fails with 

  read-tree: read-tree <key>

Is it a proof enough?

Ok, that initial one was "read a single tree to populate the index".

I consider it a fundamentally different program from "read-tree" as we
know now, which was introduced by d99082e (Make "read-tree" merge the
trees it reads by giving them consecutive states., 2005-04-15).  Ever
since that "multi-stage" version, read-tree was "starting from an empty
index, read these trees into stages #1, #2, ..."  And even that version
called the program "read-tree", not "git read-tree".  IOW, "git read-tree"
never had that "no tree is an error" restriction during its entire life.

Having said all that, I don't care that deeply either way myself.

As read-tree is a very basic and low-level Porcelain, if somebody were
using it to empty the index in an existing script, this change would
appear as a regression and hopefully will be caught eventually, and
updating such a script can be made reasonably easy if we want to be
helpful (the error message can suggest running "rm $GIT_DIR/index", for
example).