Re: Strangeness with git-add and nested repositories

From: Andrew J <andj2223@gmail.com>
Date: Apr 29, 2016, 02:11 UTC
Message-ID: <CAH6n4TdYOKT_e4MziZ1qwAX+xZ_3NJEHcKgTRK1BqAUd_mvYOQ@mail.gmail.com>
In-Reply-To: <xmqqtwil65nx.fsf@gitster.mtv.corp.google.com>

On Thu, Apr 28, 2016 at 9:48 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 7 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> When given multiple paths, e.g. "git add A/B/C A/D", it tries to
> "optimize" things by first finding common leading directory (in this
> case "A/") and doing something slightly different, and I think the
> bug Andrew saw lies in that codepath.  It is likely that the code is
> forgetting to make sure that there is no top of enclosed working
> tree in the common leading directory part of the path.

Actually, the very simplest case succeeds in adding a file from a nested repo:
==
$ mkdir parent
$ cd parent
$ git init
Initialized empty Git repository in /home/ajohnson/parent/.git/
$ mkdir subrepo
$ cd subrepo
$ git init
Initialized empty Git repository in /home/ajohnson/parent/subrepo/.git/
$ touch subfile
$ git add subfile
$ git commit -m test
[master (root-commit) 7480a2f] test
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 subfile
$ cd ..
$ git add subrepo/subfile
$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   subrepo/subfile
==

It is this more complex case that fails to add the file from the nested repo:
==
$ mkdir parent
$ cd parent
$ git init
Initialized empty Git repository in /home/ajohnson/parent/.git/
$ mkdir subrepo
$ cd subrepo
$ git init
Initialized empty Git repository in /home/ajohnson/parent/subrepo/.git/
$ touch subfile
$ git add subfile
$ git commit -m test
[master (root-commit) 36adec4] test
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 subfile
$ cd ..
$ touch parentfile
$ git add parentfile subrepo/subfile
$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   parentfile

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        subrepo/
==

Given that the very simplest case of adding a single nested file succeeds, I had assumed that the intended world order was to be able to add files from nested repos, and that the more edgy case of adding a mixture of files from the parent and nested repos failing was the bug.

For my part, I'd *much* prefer to be able to add files from nested repos, so all this "adding any files from nested repos is a bug" talk is bumming me out!

Thanks,

Andrew