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

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 30, 2016, 09:33 UTC
Message-ID: <CACsJy8C3QtVmqS_HPHjdWhBssJkZ197yz9uA3XAb-TDiOhEUmg@mail.gmail.com>
In-Reply-To: <xmqq8u17akgn.fsf@gitster.mtv.corp.google.com>

On Thu, Mar 24, 2016 at 11:50 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> 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.

Suppose I don't like git-apply's default behavior, I make an alias.ap = "apply --include=*". So far so good, but when I want to limit paths back to "subdir" (it does not have to be the same as cwd), how do I do it without typing resorting to typing "git apply" explicitly ? I don't see an option to cancel out --include=*. For "git ap --exclude=* --include=subdir" to have that effect, we need to change

for (i = 0; i < limit_by_name.nr; i++) {

in use_patch() to

for (i = limit_by_name.nr - 1; i >= 0; i--) {

Simple change, but not exactly harmless.

Off topic, but --include/--exclude should be able to deal with relative path like --include=../*.c or --include=./*. I guess nobody has complained about it, so it's not needed.

-- 
Duy