On removing files and "git-rm is pointless"

On removing files and "git-rm is pointless"

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]

Some people have recently asked questions about why we even have a
"git rm" command since it seems so pointless if you understand git's
model and "commit -a" well enough.

I wrote that command, so let me explain.

The problem I was trying to address is that a new user (me), was
trying to learn git and made it through a scenario like this:

	git init-db
	echo a > a
	git add a
	git commit

	"Cool, that works. Now let's explore file deletion:"

	rm file
	git commit

	"Hmm... that' didn't work, and git commit says:

		#   (use git-update-index to mark for commit)
		#
		#       deleted:    file

	I explored the documentation and found
	"git update-index --remove file" and thought, "this git system
	is insane! what a horrible command line that is!"

So, with "git commit", it doesn't work to just plain delete the file.

Now, a really cool thing about git and something that makes it easier
than other systems, (like cvs say), is that you don't _have_ to do
anything extra to tell it about file deletion, (nor file rename). But
to get the cool feature to work, you have to use "commit -a":

	rm file
	git commit -a

Is our new documentation going to lead users to discover this great
feature? We're talking about documenting "commit -a" as, "'add' all
tracked files then commit". It would take an exceptional stretch for a
new reader to take that sentence and realize that it would also mean
that any deleted file would also be removed from git's tracking. We're
using a verb with the _opposite_ meaning for crying out loud!

So, back to "git rm". I added it not just because some people might be
trained to tell the SCM about file removal. I added it to make "git
commit" seem more reliable, (since it can feel broken to new
users---it doesn't seem 'smart' enough to just figure out what changes
have been made to files that are being tracked).

So we should show the "smarter" behavior to users by default. Then
"git commit" wouldn't feel broken. We could even throw away "git rm"
and use its absence as a selling point for git. "Hey, git's actually
_easier_ to use than that broken stuff you've been using."

Wouldn't that be great?

-Carl




[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: On removing files and "git-rm is pointless"

[Linus Torvalds]

On Sat, 2 Dec 2006, Carl Worth wrote:
>
> Some people have recently asked questions about why we even have a
> "git rm" command since it seems so pointless if you understand git's
> model and "commit -a" well enough.

I have to admit that I'm not a big fan of "git rm".

I'd like it more if it defaulted to actually removing the file, preferably 
refusing to with an error message if the file didn't match the index. And 
then use "git rm -f" to force-remove a dirty file.

As it is, because I just find "git rm" to be annoying, I simply do what 
you talk about:

> 	rm file
> 	git commit -a

Works fine for me, and is more natural than "git rm" at least in my mind.

> Is our new documentation going to lead users to discover this great
> feature?

I definitely wouldn't object at all. The _best_ of both worlds would be 
to:

 - document how git will detect changes to files it knows about 
   (_including_ removal) automatically with "git commit -a", and make it 
   clear that "git rm" thus isn't really needed.

 - but because it makes sense to have the mirror symmetry of "git add" and 
   "git rm", and because people expect to be able to do "git rm" from 
   other systems anyway, just keep the command around, and possibly make 
   the default behaviour a bit more obvious.

On "git rm", I'd suggest:

 - with no flags: remove the working file too, but _only_ if it matches 
   the index. NOTE! This is a change in semantics, but damn, if people 
   have found "git add" hard to understand, I think "git rm" is much 
   worse, and doesn't even match "git mv" (whcih _does_ move the working 
   file, and doesn't just do a in-index move)

 - with "-f": do what "git rm -f" does now. Just force the thing. Don't 
   care whether the file is dirty in the working tree or whether it even 
   exists in the index. Just get rid of it already, both in the index 
   (regardless of state or whether it is there at all) _and_ in the 
   working tree (again, regardless of state)

One thing to look out for: "git rm" actually defaults to the recursive 
behaviour, something that might take people by surprise. If you give it a 
directory name, it will happily delete all tracked files from within that 
directory, even without "-r". That is probably a design mistake. So it 
would probably make sense to:

 - without "-r", don't do the partial matches at the beginning (but still 
   do globbing matches, of course, so "git rm dir/*" wouldn't need an 
   "-r", but "git rm -r dir/", which does the same thing, _would_ need an 
   "-r" to be effective)

Final note: arguably, the current "git rm" is a better mirror image of 
"git add" than what I suggest above. "git add" doesn't actually create the 
working file (you had to do that yourself), so you _could_ argue that "git 
rm" as it stands now is closer to the "reverse" of git add. The same is 
true of the recursive behaviour.

However, I'd argue that:

 - "rm" isn't the reverse of "add" in the first place. If we had a "git 
   subtract" file, _that_ would be the reverse of "git add" ;)

 - "rm" isn't the reverse of "add" in another sense: "rm" is just more 
   dangerous. So not having the mirror-image semantics makes sense simply 
   becaue the dangerousness of the commands aren't mirror images.

Anyway, I don't personally much care. As mentioned, I'll happily just 
remove the file and do "git commit -a" instead (or, indeed, if I want to 
play with the index, I'm perfectly comfy just doing "git update-index" 
with "--force-remove" or something - but clearly I'm more confy with the 
index and it's strangly named commands than most ;^).

Re: On removing files and "git-rm is pointless"

[Sam Vilain]

Linus Torvalds wrote:
> I'd like it more if it defaulted to actually removing the file, preferably 
> refusing to with an error message if the file didn't match the index. 

index, or HEAD version?  Otherwise you can "update-index"; "rm" without
seeing something wrong is happening.

> Final note: arguably, the current "git rm" is a better mirror image of 
> "git add" than what I suggest above. "git add" doesn't actually create the 
> working file (you had to do that yourself), so you _could_ argue that "git 
> rm" as it stands now is closer to the "reverse" of git add. The same is 
> true of the recursive behaviour.

For this reason I think that the current behaviour is not so broken.
Everywhere else, it is up to the user to make the changes to the working
copy that they want to commit.  I like git-rm because I can go:

  rm -rf whatever
  git-rm whatever

I can see why you'd want

  git-rm -u whatever

or

  rm -rf whatever
  git-commit -a

An extra flag to actually unlink the files is less likely to cause bugs
with porcelain expecting git-rm to behave as it does currently.  If it
is to be changed in backwards incompatible ways, there should probably
be a deprecation time.

"rm -u" could alter the default semantics, ie, require the extra -r
option to recurse and require -f unless things are safe.

Re: On removing files and "git-rm is pointless"

[Horst H. von Brand]

Linus Torvalds <torvalds@osdl.org> wrote:

[...]

> One thing to look out for: "git rm" actually defaults to the recursive 
> behaviour, something that might take people by surprise. If you give it a 
> directory name, it will happily delete all tracked files from within that 
> directory, even without "-r". That is probably a design mistake. So it 
> would probably make sense to:
> 
>  - without "-r", don't do the partial matches at the beginning (but still 
>    do globbing matches, of course, so "git rm dir/*" wouldn't need an 
>    "-r", but "git rm -r dir/", which does the same thing, _would_ need an 
>    "-r" to be effective)

The command should never even see the '*' here. Globbing is handled
(uniformly) by the shell. Don't loose that.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239

Re: On removing files and "git-rm is pointless"

[Sam Vilain]

Horst H. von Brand wrote:

>>  - without "-r", don't do the partial matches at the beginning (but still 
>>    do globbing matches, of course, so "git rm dir/*" wouldn't need an 
>>    "-r", but "git rm -r dir/", which does the same thing, _would_ need an 
>>    "-r" to be effective)
> 
> The command should never even see the '*' here. Globbing is handled
> (uniformly) by the shell. Don't loose that.

But;

  git-rm \*>/dev/null; git-add \*

is just so darned handy!

Re: On removing files and "git-rm is pointless"

[Linus Torvalds]

On Sat, 2 Dec 2006, Horst H. von Brand wrote:
> 
> The command should never even see the '*' here. Globbing is handled
> (uniformly) by the shell. Don't loose that.

Git supprts an extra level of globbing.

In the kernel tree, try the difference between these two command lines:

	git ls-files fs/*.c
	
	git ls-files 'fs/*.c'

and enjoy.

It's _very_ useful for a number of programs (including "git add") but I 
find it _especially_ useful for something like

	git grep jiffies -- '*.h'

where the git-level globbign is important.

Not all git programs do that globbing, but many do.

Re: On removing files and "git-rm is pointless"

[Nicolas Pitre]

On Sun, 3 Dec 2006, Sam Vilain wrote:

> Linus Torvalds wrote:
> > I'd like it more if it defaulted to actually removing the file, preferably 
> > refusing to with an error message if the file didn't match the index. 
> 
> index, or HEAD version?  Otherwise you can "update-index"; "rm" without
> seeing something wrong is happening.

Well tough then.

I think what Linus is proposing makes tons of sense.

If you do git rm by mistake then you can always do git checkout on that 
file to get it back.

If you modified it so it doesn't match the index then git rm won't do 
anything by default so you have a chance to think a bit more.

If you updated the index, didn't commit anything but then do git rm then 
you certainly wanted to really rm the file.

If not then just feel the pain of your stupidity and start again from 
the latest version.

Re: On removing files and "git-rm is pointless"

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> I think what Linus is proposing makes tons of sense.
>
> If you do git rm by mistake then you can always do git checkout on that
> file to get it back.
>
> If you modified it so it doesn't match the index then git rm won't do
> anything by default so you have a chance to think a bit more.
>
> If you updated the index, didn't commit anything but then do git rm then
> you certainly wanted to really rm the file.

FWIW, I too am in favor of the proposed fix to "git rm" as Linus
outlined.

Re: On removing files and "git-rm is pointless"

[Jakub Narebski]

Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
>> I think what Linus is proposing makes tons of sense.
>>
>> If you do git rm by mistake then you can always do git checkout on that
>> file to get it back.
>>
>> If you modified it so it doesn't match the index then git rm won't do
>> anything by default so you have a chance to think a bit more.
>>
>> If you updated the index, didn't commit anything but then do git rm then
>> you certainly wanted to really rm the file.
> 
> FWIW, I too am in favor of the proposed fix to "git rm" as Linus
> outlined.

+1. I'm also for this change. Of course if the working area version doesn't
match HEAD version git-rm should remove only index entry, and print warning
message, for example what it does now, i.e.
  rm '<filename>'
or if we want more chatty version (core.gitgor = true) it would print:
  File '<filename>' changed. Use "rm '<filename>'" to remove.
(or something like that).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: On removing files and "git-rm is pointless"

[Linus Torvalds]

On Mon, 4 Dec 2006, Junio C Hamano wrote:
> 
> FWIW, I too am in favor of the proposed fix to "git rm" as Linus
> outlined.

Note that somebody (sorry, forget who) correctly pointed out that in order 
to be "safe", the file that you "rm" has to match not only the index, but 
it should match the HEAD tree too.

If it matches both the index and the HEAD tree, a "git rm filename" is 
totally safe, since you can always get it back by just doing a

	git checkout HEAD filename

so the "git rm" really didn't lose any info, and as such, we can _happily_ 
remove the working tree copy without any concern at all.

If it doesn't match HEAD, we can't get it back as easily, so maybe that's 
the case when we want to have "git rm -f filename".

(And obviously, for all the normal reasons, if the index or HEAD doesn't 
match, the error message should be helpful and also explicitly mention the 
"-f" flag. Somehing like

	file 'x' does not match HEAD or has been staged for changes.
	Will not remove. Use '-f' to force removal.

("has been staged for changes" is just a long way of saying "index". See? 
I _can_ learn.)

Re: On removing files and "git-rm is pointless"

[Jakub Narebski]

Linus Torvalds wrote:

> (And obviously, for all the normal reasons, if the index or HEAD doesn't 
> match, the error message should be helpful and also explicitly mention the 
> "-f" flag. Somehing like
> 
>         file 'x' does not match HEAD or has been staged for changes.
>         Will not remove. Use '-f' to force removal.
> 
> ("has been staged for changes" is just a long way of saying "index". See? 
> I _can_ learn.)

I'd rather have

        File 'x' does not match HEAD or index (has been staged for changes).
        Will not remove. Use "git rm -f 'x'" to force removal.

I'd rather not learn that "staged for changes" mean "index". I'm quote
comfortable with the concept of "index" and the name "index",
thankyouverymuch.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: On removing files and "git-rm is pointless"

[Olivier Galibert]

<pet_peeve>

On Mon, Dec 04, 2006 at 07:42:26AM -0800, Linus Torvalds wrote:
> (And obviously, for all the normal reasons, if the index or HEAD doesn't 
> match, the error message should be helpful and also explicitly mention the 
> "-f" flag. Somehing like
> 
> 	file 'x' does not match HEAD or has been staged for changes.
> 	Will not remove. Use '-f' to force removal.

And you wouldn't tell which, you stupid computer?

I hate when error messages go "there is a problem that may be x, y or
z.  You can figure out which one yourself.".

Incidentally, splitting the message would allow you to add a "use git
diff x" or a "use git diff --cached x to see the differences" message.

</pet_peeve>

Re: On removing files and "git-rm is pointless"

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> If it doesn't match HEAD, we can't get it back as easily, so maybe that's 
> the case when we want to have "git rm -f filename".

Hmph.  Wouldn't this lossage the same as the lossage we are
removing the "safety valve" for, when "commit --only" jumps the
index?

Re: On removing files and "git-rm is pointless"

[Nicolas Pitre]

On Mon, 4 Dec 2006, Junio C Hamano wrote:

> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > If it doesn't match HEAD, we can't get it back as easily, so maybe that's 
> > the case when we want to have "git rm -f filename".
> 
> Hmph.  Wouldn't this lossage the same as the lossage we are
> removing the "safety valve" for, when "commit --only" jumps the
> index?

Losing an intermediate file state is much less severe than losing the 
latest file state I would think.

Re: On removing files and "git-rm is pointless"

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Mon, 04 Dec 2006 22:29:13 -0500 (EST), Nicolas Pitre wrote:
> On Mon, 4 Dec 2006, Junio C Hamano wrote:
> > Hmph.  Wouldn't this lossage the same as the lossage we are
> > removing the "safety valve" for, when "commit --only" jumps the
> > index?
>
> Losing an intermediate file state is much less severe than losing the
> latest file state I would think.

Or, in fact, the _only_ state, (if using git-rm to "undo" a git-add of
a new file, for instance).

And as for "jumping" the intermediate state without the safety valve
of "git commit files..." I'm waiting to hear what Junio has to say
about my "two conceptually distinct commit commands" proposal which
would provide a way to avoid that, (the user just indicates whether
it's index content or working-tree content that is to be committed).

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: On removing files and "git-rm is pointless"

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Mon, 4 Dec 2006, Junio C Hamano wrote:
>
>> Linus Torvalds <torvalds@osdl.org> writes:
>> 
>> > If it doesn't match HEAD, we can't get it back as easily, so maybe that's 
>> > the case when we want to have "git rm -f filename".
>> 
>> Hmph.  Wouldn't this lossage the same as the lossage we are
>> removing the "safety valve" for, when "commit --only" jumps the
>> index?
>
> Losing an intermediate file state is much less severe than losing the 
> latest file state I would think.

Very true indeed.