[BUG] 'add -u' doesn't work from untracked subdir

Hi,


As the subject says, 'git add -u' does not work from an untracked
subdir, because it doesn't add modified files to the index.  The
following script reproduces the issue:

mkdir repo
cd repo
git init
echo 1 >foo
git add foo
git commit -m first
echo 2 >foo
mkdir untracked_subdir
cd untracked_subdir
git add -u
git diff

It worked in the initial 'git add -u' implementation (dfdac5d, git-add
-u: match the index with working tree, 2007-04-20), but 2ed2c222
(git-add -u paths... now works from subdirectory, 2007-08-16) broke it
later, and is broken ever since.


Regards,
Gábor

On Wed, Sep 02, 2009 at 10:03:05AM +0200, SZEDER Gábor wrote:

As the subject says, 'git add -u' does not work from an untracked
subdir, because it doesn't add modified files to the index.  The
following script reproduces the issue:

mkdir repo
cd repo
git init
echo 1 >foo
git add foo
git commit -m first
echo 2 >foo
mkdir untracked_subdir
cd untracked_subdir
git add -u
git diff

It worked in the initial 'git add -u' implementation (dfdac5d, git-add
-u: match the index with working tree, 2007-04-20), but 2ed2c222
(git-add -u paths... now works from subdirectory, 2007-08-16) broke it
later, and is broken ever since.

It is not just untracked subdirs. Try:

  mkdir repo && cd repo && git init
  echo 1 >foo
  mkdir subdir
  echo 1 >subdir/bar
  git add . && git commit -m first
  echo 2 >foo
  echo 2 >subdir/bar
  cd subdir
  git add -u
  git diff ;# still shows foo/1 in index
  git diff --cached ;# shows subdir/bar was updated

While I have sometimes found the behavior a bit annoying[1], I always
assumed that was the intended behavior.

And indeed, in modern builtin-add.c, we find this:

        if ((addremove || take_worktree_changes) && !argc) {
                static const char *here[2] = { ".", NULL };
                argc = 1;
                argv = here;
        }

which seems pretty explicit.

-Peff

[1] I would prefer "git add -u ." to add only the current directory, and
"git add -u" to touch everything. But then, I am one of the people who
turn off status.relativepaths, so I think I may be in the minority in
always wanting to think of the project as a whole.

On Wed, Sep 02, 2009 at 04:19:17AM -0400, Jeff King wrote:

[1] I would prefer "git add -u ." to add only the current directory, and
"git add -u" to touch everything.

FWIW, I feel the same way. And there is no easy way to do that now. (cd `git
rev-parse --show-cdup`; git add -u) ?

But then, I am one of the people who
turn off status.relativepaths, so I think I may be in the minority in
always wanting to think of the project as a whole.

That mindset is one of git's greatest strengths IMO.

Clemens

[Oops, I 've just noticed that my reply to Jeff didn't made it to the
git list, because I hit 'reply' instead of 'reply to all'...]



Hi Jeff,


thanks for your quick reply.

On Wed, Sep 02, 2009 at 04:19:17AM -0400, Jeff King wrote:

On Wed, Sep 02, 2009 at 10:03:05AM +0200, SZEDER Gábor wrote:

quoted

As the subject says, 'git add -u' does not work from an untracked
subdir, because it doesn't add modified files to the index.  The
following script reproduces the issue:

mkdir repo
cd repo
git init
echo 1 >foo
git add foo
git commit -m first
echo 2 >foo
mkdir untracked_subdir
cd untracked_subdir
git add -u
git diff

It worked in the initial 'git add -u' implementation (dfdac5d,
git-add
-u: match the index with working tree, 2007-04-20), but 2ed2c222
(git-add -u paths... now works from subdirectory, 2007-08-16)
broke it
later, and is broken ever since.

It is not just untracked subdirs. Try:

  mkdir repo && cd repo && git init
  echo 1 >foo
  mkdir subdir
  echo 1 >subdir/bar
  git add . && git commit -m first
  echo 2 >foo
  echo 2 >subdir/bar
  cd subdir
  git add -u
  git diff ;# still shows foo/1 in index
  git diff --cached ;# shows subdir/bar was updated

While I have sometimes found the behavior a bit annoying[1], I
always
assumed that was the intended behavior.

And indeed, in modern builtin-add.c, we find this:

        if ((addremove || take_worktree_changes) && !argc) {
                static const char *here[2] = { ".", NULL };
                argc = 1;
                argv = here;
        }

which seems pretty explicit.

Since then I looked at the man page (I should have done that right
away ;), and it says under the description of -u that "If no paths are
specified, all tracked files in the current directory and its
subdirectories are updated."  So this is indeed the intended
behaviour, but I was just not aware of it.  Oh well, sorry for the
noise.

[1] I would prefer "git add -u ." to add only the current directory,
and
"git add -u" to touch everything. But then, I am one of the people
who
turn off status.relativepaths, so I think I may be in the minority
in
always wanting to think of the project as a whole.

I don't really know which would I prefer.

I was updating some Javadoc documentation in Eclipse, and checking the
generated docs in terminal, deep down in an untracked subdir, and
performed some 'add -u ; commit --amend' from there (and was rather
surprised after the fifth amend to see all the changes still in the
worktree).  Doing perform the desired add -u from there I should have
run 'git add -u ../../../../../..', what doesn't seem very convenient.
But since this was the first time I've done that since 2007-08-16, I
guess it's not a very common use case.


Gábor

On Fri, Sep 04, 2009 at 09:02:16AM +0200, Clemens Buchacher wrote:

On Wed, Sep 02, 2009 at 04:19:17AM -0400, Jeff King wrote:

quoted

[1] I would prefer "git add -u ." to add only the current directory, and
"git add -u" to touch everything.

FWIW, I feel the same way. And there is no easy way to do that now. (cd `git
rev-parse --show-cdup`; git add -u) ?

I suspect it is too late to change it due to compatibility issues. OTOH,
I think the intent of v1.7.0 is to allow a few small breakages like
these. You could always write an RFC patch and generate some discussion;
I'm not 100% sure that there are enough people that agree with us to
change the default.

I guess we could add a "git add --absolute" option, though it is
slightly annoying, because I generally do not realize that I needed to
use such an option until several minutes after running "git add".

I would be fine with a "be absolute, not relative" config option such as
what we have for status (in fact, a global "be absolute, not relative"
option to cover all commands might be handy). The only obstacle is that
I think "git add" is often used as plumbing in scripts (arguably, they
should be using update-index, but "git add ." is just so convenient).

-Peff