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

[Junio C Hamano <gitster@pobox.com>]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Quoting Junio C Hamano <gitster@pobox.com>
>
>> 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 <torvalds@ppc970.osdl.org>
>  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).