Jakob Pfender <jpfender@xxxxxxxxxxxxx> 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.
--
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