Re: [PATCH/RFC] add: listen to --ignore-errors for submodule-errors

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 26, 2012, 04:09 UTC
Message-ID: <7v395iemt2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vfw9ieqvh.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 37 quoted lines

> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> I recently tried to do the following in the msysGit-repo:
>>
>>  $ git add --ignore-errors -- */.gitignore
>>  fatal: Path 'src/git-cheetah/.gitignore' is in submodule 'src/git-cheetah'
>>
>> I was a bit puzzled by this; I explicitly specified --ignore-errors
>> because I did not want to be stopped due to src/git-cheetah/.gitignore
>> being located in a submodule.
>
> If I recall correctly, originally --ignore-errors was added was by
> those who (arguably misguidedly) wanted to randomly run "git add"
> that can potentially race with ongoing working tree updates
> (i.e. think of a poor-man's unreliable snapshotting filesystem), to
> which "git add" will notice that the working tree file it was asked
> to index changed while it was reading and error out.  Also on some
> systems, "git add" on files that are currently open may not be able
> to read from them, which would also cause a run-time error.  The
> kind of errors the option was meant to ignore were "these paths are
> perfectly OK to add, but for some reason, adding them fails at this
> moment, and for the purpose of poor-man's unreliable snapshot, it is
> OK not to pick the exact current state up, as we will pick it up the
> next round", not your kind of request that will lead to an error of
> the "adding this path will break the structural integrity of the
> repository and git should error out" kind.
>
>> The documentation seems to suggest that this is what is supposed to
>> happen, and this seems like the most likely behavior that the user
>> wanted. After all, there's no good reason submodules are special
>> in this regard, no?
>
> How does "git add .git" or "git add .git/config" behave with your
> patch applied?  It is exactly the same kind of error that breaks the
> structural integrity of the repository as adding src/cheetah/.gitignore
> to the top-level project repository, and there is no good reason to
> special case submodules, either.

For that matter, running "git add ../../foo" from the top-level of the working tree falls into the same category. There are boundaries in both upward and downward directions that define the area you could add to the index.

Now, I am not saying that "--ignore-errors" should _never_ mean to ignore errors of this kind. I was merely giving the historical background for the semantics you are observing. I personally think it might even be an improvement if you made the option to instruct the command to consistently ignore requests to add these paths outside the working tree boundary in any direction (not just the downwards boundary defined by the presense of a submodule, but the downwards boundary defined by the ".git" directory, and the upward boundary at the root of the working tree), and add only remaining valid paths to the index. I do not think it is the right thing to special case only the submodules, though.