cant difference
and it is safe to apply with reduced context, instead of blindly
accepting a fuzzy patch application.
It's not my call about the defaults, but users can be surprised by
such changes.
For the dangers related to fuzzing, is there more info? I found
and old post on this from Linus calling fuzzing dangerous but
from what I could tell about my patch that wouldn't apply
without fuzzing, the only differ
Junio C Hamano writes:
> Making "am -3" default may also scare users who are not exactly
> comfortable with reading "git diff" output during a conflicted merge
> and resolving a conflict, but other than that there shouldn't be any
> downside.
Another obvious downside is that there are those of u
Jeff King writes:
> I dunno. I always use it, but I'm not sure if there are any downsides,
> aside from a little extra processing time. It does have some
> incompatibilities with other options. And I think it kicks in rename
> detection (but I might be mis-remembering another feature). That could
On Fri, Feb 10, 2017 at 01:37:12PM -0800, Stefan Beller wrote:
> > This is not exactly an answer to your question, but "git am -3" is often
> > a better solution than trying to fuzz patches. It assumes the patches
> > are Git patches (and record their origin blobs), and that you have that
> > blob
On Fri, Feb 10, 2017 at 12:57 PM, Jeff King wrote:
> On Fri, Feb 10, 2017 at 11:20:59AM -0800, Nick Desaulniers wrote:
>
>> I frequently need to backport patches from the Linux kernel to older
>> kernel versions (Android Security). My usual workflow for simple
>> patches is:
>>
>> 1. try `git am
On Fri, Feb 10, 2017 at 11:20:59AM -0800, Nick Desaulniers wrote:
> I frequently need to backport patches from the Linux kernel to older
> kernel versions (Android Security). My usual workflow for simple
> patches is:
>
> 1. try `git am patch.txt`.
This is not exactly an answer to your question
Nick Desaulniers writes:
> I frequently need to backport patches from the Linux kernel to older
> kernel versions (Android Security)
> ...
> My question is, why does `patch` seem to do a better job at applying
> patches than `git am`? It's almost like the `git` tools don't try to fuzz
> the
I frequently need to backport patches from the Linux kernel to older
kernel versions (Android Security). My usual workflow for simple
patches is:
1. try `git am patch.txt`.
2. if that fails try `git apply -v patch.txt` then add commit message
manually.
3. if that fails try `patch -p1 < patch.txt`
9 matches
Mail list logo
