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

Sverre Rabbelier [off-list ref] writes:

On Fri, Dec 18, 2009 at 13:32, Junio C Hamano [off-list ref] wrote:

quoted

Sure, it will empty the index, so it is dangerous in the same sense that
"reset --hard" is dangerous because it will wipe all your local changes,
or "rm -rf it" will remove everything underneath it.

With the difference that both 'reset --hard' and 'rm -rf' need a flag
to do their destructive work? Although 'git reset' might be just as
destructive if you've been using 'git add -p' a lot or something,
mhh...

I'll grant you that at least "rm -rf it" names "it" that will be wiped
very explicitly.  But just like the index and the work tree plus the index
are the implicit targets to "reset" and "reset --hard" respectively, the
index is the implicit target to "read-tree".

So it may be "dangerous" in the sense that "it would change things and if
you meant to do something else the end result would be different from what
you wanted to do".  In that sense, "log", "cat-file" and friends may be
danger-free commands and all others would be dangerous.  You might type
"commit" when you meant to say "commit -a" and record an incomplete state;
it is "dangerous" in that sense.

These are part of their feature.

Heya,

On Fri, Dec 18, 2009 at 13:49, Junio C Hamano [off-list ref] wrote:

You might type
"commit" when you meant to say "commit -a" and record an incomplete state;
it is "dangerous" in that sense.

Speaking of which, it has hit me multiple times that I craft out a
commit with 'git add -p' and then do "git commit -am 'foo some bars'"
and lose all my hard work (because I'm used to typing 'git commit -am'
for temporary commits). I'd be happy if "git commit -am" learned to
second-guess me when I already have something in the index.

These are part of their feature.

Fair enough, then perhaps it is time for "core.nodataloss" which
either logs states to a seperate reflog (so that you can go back to
the state you were in before doing 'git read-tree') or interactively
informs the user that this will command will result in data loss
(although that sounds a tad too much like Window's "Are you sure?"
dialogs).

-- 
Cheers,

Sverre Rabbelier

On Freitag, 18. Dezember 2009, Junio C Hamano wrote:

I'll grant you that at least "rm -rf it" names "it" that will be wiped
very explicitly.  But just like the index and the work tree plus the index
are the implicit targets to "reset" and "reset --hard" respectively, the
index is the implicit target to "read-tree".

[...]  You might type
"commit" when you meant to say "commit -a" and record an incomplete state;
it is "dangerous" in that sense.

These are part of their feature.

Really? "rm -rf", "reset --hard", "commit -a": yes, RTFM. But "read-tree" (w/o 
arguments): no. There is no such sign in the documentation. Since the 
operation of the latter is dubious at best, I'd rather change the program 
than the documentation.

How about this commit message, then?

Subject: [PATCH] read-tree: at least one tree-ish argument is required

Running read-tree without any arguments purges the index, but this is not
documented. This behavior is dubious at best because contrary to many
other commands, it does not use HEAD if nothing else is specified.

If one really wants to clear the index, this can be achieved with
'git rm --cached .' or 'rm -f .git/index' in a more explicit way.

Signed-off-by: Johannes Sixt <redacted>

Johannes Sixt [off-list ref] writes:

Running read-tree without any arguments purges the index, but this is not
documented. This behavior is dubious at best because contrary to many
other commands, it does not use HEAD if nothing else is specified.

If one really wants to clear the index, this can be achieved with
'git rm --cached .' or 'rm -f .git/index' in a more explicit way.

One can (I think) also always use "git read-tree <empty tree>",
where <empty tree> = 4b825dc642cb6eb9a060e54bf8d69288fbee4904

-- 
Jakub Narebski
Poland
ShadeHawk on #git