git-rm semantics (was: The philosophy behind my directory proposal in a nutshell)

Following up on the git-rm note:

    [As a note aside: working directories get removed when their
    corresponding tree collapses and disappears from the
    repository.  I should think it only consistent if the same
    happened with git-rm: let the file by default disappear at
    the moment when it gets removed from the repository,
    implying --cached.  Namely, let

    git-rm some-file
    git-add some-file

    be a noop, regardless whether the file was registered
    previously.  This also implies that git-rm will always leave
    unregistered files alone.]

Ok, this is somewhat incorrect: if we call git-rm and the file still
exists, this is strictly speaking the same situation as calling
git-add when a file does not exist.

And that gives:
fatal: pathspec 'geo' did not match any files
whether or not the repository has an idea about the file.

So in analogy, git-rm on an existing file could possibly made to barf.

Anyway, the following appears inconsistent to me:

touch geo
git-add geo
git-commit -m xxx -a
git-rm geo
[Now geo is gone]
git-add geo
[geo is complained about as unknown]
git-checkout geo
[geo is complained about as unknown!]

Now the last complaint clearly is quite a nuisance, because
git-checkout .
_will_ resurrect geo.

So for consistency's sake, it would appear that git-rm should really
only schedule a removal, and pull through only at the moment where the
file is actually removed from the repository.  There is a slight
discordance with git-add in that git-add requires the existence of the
file at the time of the add.  That is inevitable since git records the
_contents_ of the file at the time of the add.  git-rm does not need
any such information.

Now what if a file disappears before we commit, namely
touch woozle
git add woozle
rm woozle
?

Woozle will in that case get committed if and only if the commit is
done without the -a option.

Makes sense.  So in a nutshell: git-rm should not look at the working
directory.  That's the business of the commit.  When the repository
copy gets removed, this is the right time to remove the corresponding
file, and this is perfectly equivalent with the case for trees.

What _is_ strange is that a git-rmed file can't be restored by naming
it for a checkout.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum