[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0901261411310.3465@localhost.localdomain>
Date: Mon, 26 Jan 2009 14:19:50 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Sam Ravnborg <sam@...nborg.org>
cc: Dave Airlie <airlied@...il.com>, Dave Airlie <airlied@...ux.ie>,
dri-devel@...ts.sf.net,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [git pull] drm-fixes
On Mon, 26 Jan 2009, Linus Torvalds wrote:
> >
> > There must be easier ways to do so I think.
>
> Um. Yes. Something like
>
> git am -s -C1
>
> which ends up requiring just a single line of context for the patch to
> apply, exactly like the GNU 'patch' program.
>
> The difference being that GNU patch does that incredibly broken thing by
> default, and makes it easy to apply a patch that was already applied quite
> by mistake, because it still works. Git will require you to say explicitly
> that it's ok to have just a single line of context.
Btw, I _really_ don't want people using -C1 by default. It really is a
broken default, and there is a reason why I dislike GNU patch for applying
almost any patch that makes any sense what-so-ever.
So please work with the stricter git defaults. You can still get patches
that silently apply even if they don't work (there's nothing magical about
three lines of context - a patch may still apply in the wrong place), but
it's a lot harder to get those silent screw-ups.
Then, when the strict model doesn't work, take a look by hand, and try to
figure out why it didn't work. If you decide that you really do want to
apply the patch, and the changes near-by that causes it to not apply any
more were really not relevant and don't affect the behaviour of the patch,
_that_ is when you can use -C1 and --whitespace=fix etc to make it apply
despite not being a 100% match.
So don't use -C1 and whitespace-fixup blindly. That way lies madness. It
may _seem_ to be much easier, and yes, 95% of the time it will do the
right thing, but when it doesn't, it silently does bad things. Please only
use those flags when you've literally spent a few seconds of a real human
brain to look at why they are needed.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists