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

[Johannes Sixt <j.sixt@viscovery.net>]

On Freitag, 18. Dezember 2009, Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> > You have queued 1/2 (filter-branch: remove an unnecessary use of
> > 'git read-tree') of this 2-patch series, but I haven't seen any comments
> > about this 2/2 nor is it queued. Did it fall through the cracks?
>
> No.  I think saying "is not allowed" is going a bit too far [*1*].

Yes, you said that, but in response to the footnote in 1/2.

> The 
> documentation does not list it as a commonly useful thing, that's all.

IMO, not only is it not useful, but it is also dangerous - it erases the 
index!

> When a user wants to have an empty index, and does not want to touch files
> under $GIT_DIR with any non-git tools (e.g. "rm -f $GIT_DIR/index) for
> some religious reasons, "read-tree" without a tree would be one valid way
> to do so [*2*].
> *2* I suspect "rm --cached ." might be another, but it would probably be
> much more expensive.

For an operation like this, shouldn't we advocate this alternate instruction 
(which explicitly tells what is wanted) rather than the implicit and 
undocumented operation of parameter-less read-tree?

> We need to make arguments like "'read-tree' given by mistake to empty the
> index is risky", "'read-tree' as 'rm -f $GIT_DIR/index' replacement has
> little value", and "'read-tree' as 'rm -f $GIT_DIR/index' replacement is
> the best way to get an empty index" to weigh pros and cons between two
> possible approaches before deciding which way to go, but in a pre-release
> freeze, I wasn't in the mood to be one who is doing the arguments myself.

Sorry to drag you into this discussion, but I felt this change is maint-worthy 
(because the behavior is not only risky, but dangerous).

-- Hannes