Re: [RFC] git rm -u

Piotr Krukowiecki [off-list ref] writes:

Do you mean "git add" will be disallowed without "." or ":/" argument?
Or will this change in future and "git add" without argument will me
"whole tree", same as ":/" ?

No.  This is only about "git add -u<RETURN>", not any other forms of
"git add ...with or without other args...".

"git add -u<RETURN>" historically meant, and it still means, to
"update the index with every change in the working tree", even when
you are in a subdirectory.

Back when "git add -u" was invented, we didn't have the ":/", which
lets us tell commands that take pathspecs "I want everything from
the top of the working tree.".  If "git add -u<RETURN>" limited its
operation to the current directory, after working everywhere in the
working tree, cd'ing around and ending up to be in a subdirectory
somwhere deep, you had to "cd ../../.. && git add -u", which was
cumbersome.  If "git add -u" always meant the whole tree, limiting
it to the current directory with "git add -u .<RETURN>" was easy,
and that is why the default was chosen to the "whole tree".

Because we have ":/" these days, changing something that limits its
action to the current directory by default to instead work on the
whole tree no longer makes much sense.  That is, if we _were_ to
change "git add -u<RETURN>", it would be in the opposite direction,
i.e. to update the index only with the paths below the current
directory.

Such a change has to be done carefully.  Existing users do expect
the current behaviour, so we have to first _break_ their fingers and
habits and train them to say "add -u :/" when they mean the whole
tree operation.  Silently accepting "add -u" and changing its
meaning to update the index only with the paths below the current
directory will cause them trouble by leaving changes they _thought_
they added out of the index, and is an unacceptable change.

The first step of migration is "git add -u<RETURN>" that loudly
warns, so that uses of that form in scripts are updated before the
second step to avoid a flag-day breakage and start traing fingers
and habits of the users.

The second step is to make "add -u<RETURN>" fail, again with a
message that tells users to be explicit and add ":/" or "." at the
end if they mean "the whole tree" or "the current directory".

After keeping Git in that secnd step for sufficiently long time to
train users to type ":/" or "." explicitly, we can then finally
switch the default of "git add -u<RETURN>" to limit it to the
current directory, instead of failing the command.

On Mon, Jan 21, 2013 at 10:23 AM, Junio C Hamano [off-list ref] wrote:

No.  This is only about "git add -u<RETURN>", not any other forms of
"git add ...with or without other args...".

"git add -u<RETURN>" historically meant, and it still means, to
"update the index with every change in the working tree", even when
you are in a subdirectory.

But it *currently* limits itself to a subdirectory - does not work on
whole tree:

piotr@PIOTR-X73 ~/dv/test/dir1 (master)
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   dir2/file2.txt
#       modified:   file1.txt
#       modified:   ../file.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

piotr@PIOTR-X73 ~/dv/test/dir1 (master)
$ git add -u

piotr@PIOTR-X73 ~/dv/test/dir1 (master)
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   dir2/file2.txt
#       modified:   file1.txt
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   ../file.txt
#

piotr@PIOTR-X73 ~/dv/test/dir1 (master)
$ git --version
git version 1.8.0.msysgit.0



--
Piotr Krukowiecki