Re: [PATCH/WIP 03/11] t5403: avoid doing "git add foo/bar" where foo/.git exists
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Oct 30, 2011, 09:55 UTC
- Message-ID
- <CACsJy8Ae1MPYzjoouZoFCU6Ltr9UznukfuTrJb=OUJYr9VTYSg@mail.gmail.com>
- In-Reply-To
- <7vaa8jrm6a.fsf@alter.siamese.dyndns.org>
On Sun, Oct 30, 2011 at 2:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> 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().
Show 15 quoted lines
> 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