On Freitag, 18. Dezember 2009, Junio C Hamano wrote: > Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html