Re: Strangeness with git-add and nested repositories

From: Andrew J <andj2223@gmail.com>
Date: Apr 28, 2016, 06:10 UTC
Message-ID: <CAH6n4TfvybZyAYLkzyjfaP=2ZkirpacTgVQApF3bZT-j8=_Qng@mail.gmail.com>
In-Reply-To: <CAGZ79kZhATfP1FpXnhivCa_Az-3KADSCReOo68E2Q3s29x5HNw@mail.gmail.com>

Hi Stefan,

On Wed, Apr 27, 2016 at 9:08 AM, Stefan Beller <sbeller@google.com> wrote:

Show 5 quoted lines

> I think (pure speculation), that it the error is in the context
> (repository) switching logic.
> What happens if you alter the order, i.e. give testfile first and then
> the files in the nested
> repos?

Interestingly, reversing the order produces the same result (the testfile is added, the nested files are not).

I've also noticed that running something like 'git status testfile nestedfiles' results in the nested files being omitted from the git status output; I'd expect them to be printed by git-status as untracked files. So it appears the problem is not isolated to git-add.

To give some context, my use case is that I have a parent project that links to numerous chromium libraries, thus my parent project needs access to many of chromium's headers at build time. I wanted to make these headers available to other developers without them needing to check out all of chromium. So I add all the chromium headers to the parent project with something like: find deps/chromium/src -name "*.h" | xargs git add -- I was weirded out to find that many of the header files weren't being added, as I've already described.

I ultimately worked around this by doing: find chromium/src -name "*.h" | xargs -n 1 git add Since each file gets added separately, this is quite slow. So it'd be nice if this little bug was fixed someday :)

As you probably know, Chromium is comprised of many hundreds of nested repos, so that aided in manifesting this issue.

Thanks, Andrew