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

From: David Kastrup <dak@gnu.org>
Date: Jul 21, 2007, 23:40 UTC
Message-ID: <85bqe5qqag.fsf@lola.goethe.zz>
In-Reply-To: <85fy3hqtwl.fsf@lola.goethe.zz>

Following up on the git-rm note:

Show 13 quoted lines

>     [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