Jan Hudec <bulb@xxxxxx> writes:
>> What's wrong with the behavior of "hg rm"?
>> What's wrong with the behavior of "svn rm"?
>> What's wrong with the behavior of "bzr rm"?
>> (no, I won't do it with CVS ;-) )
>>
>> None of these commands have the problem that git-rm has.
>
> Hm. They all behave roughly the same: They unversion the file and unlink it,
> unless it is modified, in which case they unversion it and leave it
> alone.
Yes. Roughly, they'll ask you a --force flag whenever you'd risk
data-loss. bzr gives you the choice between --force and --keep (that
would be --cached in git) if the file doesn't match HEAD.
> Now git has the extra complexity that index contains also content of the
> file. But the behaviour can be easily adapted like this (HEAD = version in
> HEAD, index = version in index, tree = version in tree):
^^^^- I suppose you meant "version"
here since you don't use
"tree" after.
> - if (HEAD == index && index == version) unversion and unlink
Just to be more precise:
- if (HEAD == index && index == version) unversion and
* if (--cached is not given) unlink
* else do nothing
> - else if (HEAD == index || index == version) unversion
> - else print message and do nothing
>
> Would you consider that a sane behaviour?
To me, that's a sane behavior.
It makes a few senarios easy and safe, like this:
$ git add <whatever>
# Ooops, no, I didn't want to version this one :-(
$ git rm some-file
# Cool, I just cancelled my mistake without loosing anything ;-)
One benefit is: you don't have to use "-f" for a non-dangerous
senario. That seems stupid, but for the plain "rm" command, the "-rf"
is hardcoded in the fingers of many unix users, and I know several
people having lost data by typing it a bit too mechanically (with a
typo behind, like forgetting the "*" in "*~" ;-).
I'll try writting patch for that if people agree that this is saner
that the current behavior.
--
Matthieu
-
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
