threads / discuss / 26853

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

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

## tl;dr

2 messages between Mar 24, 2011 and Mar 24, 2011.

replies: 1people: 2as markdown or json

Jakob Pfender· Mar 24, 2011, 17:07 UTC · lore

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?
Junio C Hamano· Mar 24, 2011, 18:28 UTC · re: Jakob Pfender · lore

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

Jakob Pfender <jpfender@elegosoft.com> writes:
Show 9 quoted lines
> 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.

← back to recent threads