Re: git-apply does not work in a sub-directory of a Git repository
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Mar 24, 2016, 10:49 UTC
- Message-ID
- <CACsJy8CTix-ZwN04MwYTB+JEtDCV27QVf7_0vWmhUSVCwU29Jg@mail.gmail.com>
- In-Reply-To
- <xmqqlh59cexj.fsf@gitster.mtv.corp.google.com>
On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 38 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
>> See
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/288316/focus=288321
>>
>> I agree it is bad that it silently ignores the path outside the
>> directory. When run with --verbose, we should say "Skipped X that
>> is outside the directory." or something like that, just like we
>> issue notices when we applied with offset, etc.
>
> Another thing we may want to do is to loosen (or redo) the logic
> in builtin/apply.c::use_patch()
>
> static int use_patch(struct patch *p)
> {
> const char *pathname = p->new_name ? p->new_name : p->old_name;
> int i;
>
> /* Paths outside are not touched regardless of "--include" */
> if (0 < prefix_length) {
> int pathlen = strlen(pathname);
> if (pathlen <= prefix_length ||
> memcmp(prefix, pathname, prefix_length))
> return 0;
> }
>
> 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.Interesting. Disabling that comment block seems to work ok. So git-apply works more like git-grep, automatically narrowing to current subdir, rather than full-tree like git-status. git-apply.txt should probably mention about this because (at least to me) it sounds more naturally that if I give a patch, git-apply should apply the whole patch.
We probably should show a warning if everything file is filtered out too because silence usually means "good" from a typical unix command. It could be guarded with advice config key, and should only show if it looks like there are matching paths on worktree, but filtered out. Hmm?
> That way, the plain-vanilla use would still retain the "when working > in subdirectory, we only touch that subdirectory" behaviour, which > existing scripts may depend on, but users can loosen the default as > necessary.
-- Duy