Re: git-apply does not work in a sub-directory of a Git repository

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 24, 2016, 16:50 UTC
Message-ID: <xmqq8u17akgn.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1458820579-31621-1-git-send-email-pclouds@gmail.com>

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

Show 14 quoted lines

>> On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> The include/exclude mechanism does use wildmatch() but does not use
>>> the pathspec mechanism (it predates the pathspec machinery that was
>>> made reusable in places like this).  We should be able to
>>>
>>>     $ cd d/e/e/p/d/i/r
>>>     $ git apply --include=:/ ../../../../../../../patch
>>>
>>> to lift this limitation.  IOW, we can think of the use_patch() to
>>> include only the paths in the subdirectory we are in by default, but
>>> we can make it allow --include/--exclude command line option to
>>> override that default.
>
> I went with a new option instead of changing --include.

It might be a "workable" band-aid, but would be an unsatisfying UI if it were the endgame state. You do not say "git grep --whole" (by the way, "whole" is a bad option name, as you cannot tell "100% of *what*" you are referring to--what you are widening is the limit based on the location in the directory structure, so the option name should have some hint about it, e.g. "full-tree" or something) and this command will become an odd-man-out.

I haven't thought things through, but thinking out aloud a few points...

  An existing user/script may be working in a subdirectory of a huge
  working tree and relies on the current behaviour that outside world
  is excluded by default, and may be passing --exclude to further
  limit the extent of damage by applying the patch to a subset of
  paths in the current directory that itself is also huge.  And that
  use case would not be harmed by such a change.

  On the other hand, an existing user/script would not be passing an
  "--include" that names outside the current subdirectory to force
  them to be included, because it is known for the past 10 years not
  to have any effect at all.

So a better alternative may be to conditionally disable the "Paths outside are not touched regardless of --include" logic, i.e. we exclude paths outside by default just as before, but if there is at least one explicit "--include" given, we skip this "return 0".

That way, we do not have to commit to turning --include/--exclude to pathspec (which I agree is a huge change in behaviour that may not be a good idea) and we do not have to add "--full-tree" that is only understood by "apply" but not other commands that operate on the current directory by default.

I agree that the "excluded because the path is outside cwd" should be reported just like we show notices when applying a hunk with offset, and that the "excluded because the path is outside cwd" should be documented.