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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux