From: Nguyen Thai Ngoc Duy Date: Sun, 30 Oct 2011 09:55:54 GMT Subject: Re: [PATCH/WIP 03/11] t5403: avoid doing "git add foo/bar" where foo/.git exists Message-ID: In-Reply-To: <7vaa8jrm6a.fsf@alter.siamese.dyndns.org> On Sun, Oct 30, 2011 at 2:08 PM, Junio C Hamano wrote: >        Side note. I just did this and I am not getting what you saw above. > >        $ mkdir -p /var/tmp/j/y && cd /var/tmp/j/y >        $ git init; git init clone2 >        $ : >3; : >clone2/2 >        $ GIT_DIR=clone2/.git git add clone2/2 3 >        $ GIT_DIR=clone2/.git git ls-files >        3 >        clone2/2 > >        The behavour is different when clone2/.git already has commit, and >        whatever codepath that gives these two different behaviour needs >        to be fixed. It's resolve_gitlink_ref() in treat_directory(). I think replacing that call() with is_git_directory() would fix this problem. We may want to do the same with remove_dir_recursively(). > When GIT_DIR=clone2/.git is given, however, the caller explicitly declines > the repository discovery. We do not know how the repository we are dealing > with (which we were explicitly told with $GIT_DIR) and a directory whose > name is ".git" under "clone2" we happened to find in read_directory() > relates to each other, especially when our index does not have clone2 as > our submodule. > > We however *do* know that our working tree is our current directory, so > it would be wrong to do this: > >    $ GIT_DIR=clone2/.git git add clone2/2 3; echo $? >    error: 3 is outside our repository, possibly goverened by .git >    1 > > The command should just add clone2/2 and 3 as it was told to. I am concerned about clone2/2 in this case, not 3. I guess we can check if clone2/.git is the repo we are using. If it is, skip it. -- Duy