Duy Nguyen writes:
> But your suggestion is good and I can't think of any better. We could
> introduce pathspec as ftiler after "--", but it does not look elegant,
> and it overlaps with --include/--exclude.
I was imagining that we would allow the magic pathspec syntax used
On Thu, Mar 24, 2016 at 11:50 PM, Junio C Hamano wrote:
> 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
On Thu, Mar 24, 2016 at 11:50 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>>> On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano wrote:
The include/exclude mechanism does use wildmatch() but does not use
the
Junio C Hamano writes:
> 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
Nguyễn Thái Ngọc Duy writes:
>> On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano 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
Duy Nguyen writes:
>> 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
+Brian who also had issues with git-apply.
On Thu, Mar 24, 2016 at 5:49 PM, Duy Nguyen wrote:
> On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> See
>>>
>>>
On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano wrote:
> Junio C Hamano 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.
On Wed, Mar 23, 2016 at 8:51 PM, Junio C Hamano wrote:
> I think we do have --no-index (which is why I am largely ignoring
> the rest of your message as uninformed speculation for now).
--no-index command line flag is there for git-apply but unfortunately not
documented.
Also
Junio C Hamano 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."
Duy Nguyen writes:
> 1) add --no-index to force git-apply ignore .git, --git (or some other
> name) to apply patches as if running from topdir, add a config key to
> choose default behavior
I think we do have --no-index (which is why I am largely ignoring
the rest of your
On Wed, Mar 23, 2016 at 5:14 AM, Stefan Beller wrote:
>> Hello everyone,
>> As you observed, patch wasn't applied. Is it intended behaviour of
>> git-apply? Usually to apply the patch I have to copy it to top directory
>> and then use git-apply.
>>
>> I tried out git-am to
On Tue, Mar 22, 2016 at 5:10 AM, Mehul Jain wrote:
> Hello everyone,
>
> Recently while using git-apply, I observed that if git-apply is used in a
> sub-directory of a Git repository then it silently dies without doing
> anything.
>
> Here's what I did
>
> ~ $mkdir
Hello everyone,
Recently while using git-apply, I observed that if git-apply is used in a
sub-directory of a Git repository then it silently dies without doing
anything.
Here's what I did
~ $mkdir example
~ $cd example
example $git init
Initialized empty Git repository in /home/mj/example/.git/
14 matches
Mail list logo