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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[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:
>
> > 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

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]