[RFD] git update-index --remove frotz --add frotz expected behaviour?

[RFD] git update-index --remove frotz --add frotz expected behaviour?

[Jakob Pfender]

I'm a bit stumped by update-index' behaviour when calling --remove and 
--add on the same file in that order:

$ touch frotz
$ git update-index --add frotz
$ rm frotz
$ git status -s
AD frotz
$ git update-index --remove frotz --add frotz
$ echo $?
0
$ git status -s
$

Notice that update-index doesn't complain that I'm trying to add a file 
that doesn't exist, and it's returning with 0.

Is this expected behaviour? Shouldn't I get some sort of error message 
telling me that I'm trying to add a file I've just removed? Compare:

$ touch xyzzy
$ git update-index --add xyzzy
$ rm xyzzy
$ git update-index --remove xyzzy
$ git update-index --add xyzzy
error: xyzzy: does not exist and --remove not passed
fatal: Unable to process path xyzzy

Can anyone explain this to me?

Re: [RFD] git update-index --remove frotz --add frotz expected behaviour?

[Junio C Hamano]

Jakob Pfender <jpfender@elegosoft.com> writes:

> I'm a bit stumped by update-index' behaviour when calling --remove and
> --add on the same file in that order:
>
> $ touch frotz
> $ git update-index --add frotz
> $ rm frotz
> $ git status -s
> AD frotz
> $ git update-index --remove frotz --add frotz

This falls into "if it hurts, don't do that" category.  The canonical
order of command line parameters is to have --options first and then
revisions and finally pathspecs.  update-index does not take any revs, so
you would be saying "git update-index --add --remove frotz".

For historical reasons, "update-index" never adds paths that are not
already in the index unless you tell it that it is Ok to do so with
"--add" option.  Also it does not remove without "--remove" even after you
removed the paths from your working tree.  The important point to note
here is that these two options only tell the command it is allowed to add
or remove the path from the index, and what happens solely depends on what
you have in the working tree.

If you do have Makefile and Rakefile already in the index, and if you only
have Makefile and Nakefile in the working tree,

    $ git update-index Nakefile

will error out because you didn't allow the command to add a new path to
the index by giving --add,

    $ git update-index Rakefile

will error out because you didn't allow the command to remove an existing
path from the index by giving --remove.  As an obvious consequence:

    $ git update-index --add --remove {M,N,R}akefile

will reflect the state of these three paths in the working tree to the
index.  It won't leave Rakefile in the index _only_ because you don't have
it in the working tree (and you allowed the command to remove it by giving
the --remove option); "--add" on the command line is _not_ an instruction
to "add" (implying that the command should error out because it cannot add
that which does not exist), it merely is a permission to the command.

And this is not going to change.