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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 19, 2009, 04:43 UTC
Message-ID: <7veimrmv3r.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20091219122509.6117@nanako3.lavabit.com>

Nanako Shiraishi <nanako3@lavabit.com> writes:

Show 20 quoted lines

> 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).