Message-ID: <1374687963.3356.145.camel@gandalf.local.home>
Date:	Wed, 24 Jul 2013 13:46:03 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"gregkh@...uxfoundation.org >> Kroah-Hartman, Greg" 
	<gregkh@...uxfoundation.org>, Shuah Khan <shuah.kh@...sung.com>,
	Shuah Khan <shuahkhan@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [ 000/103] 3.10.3-stable review

On Wed, 2013-07-24 at 10:24 -0700, Linus Torvalds wrote:
> On Wed, Jul 24, 2013 at 10:16 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > I don't know why "git apply" doesn't do it by default. Why would you
> > want to apply a patch without having git track new files?
> 
> There's a few reasons for the behavior:
> 
>  - it turns out that for most simple patches, you don't want to add
> them to the index, and you want to stage them separately. Doing a "git
> apply", you'd normally expect the end result to not be staged, so that
> it shows up in "git diff", and then you can do your normal "git add"
> or "git commit -a" or whatever. Yes, this means that you need to know
> about new files, but the expected use is *not* to apply a patch
> blindly and then not even care about the index.

Heh, I usually still use the --index, and then just do "git diff HEAD"
to check out what changed. If I don't like it, a "git reset --hard"
fixes things.

> 
>  - "git apply" is actually also designed to be a *replacement* for
> "patch". In particular, you can use it outside a git repository,

OK, this makes more sense.

> exactly like you'd use the standard "patch" program. Except unlike the
> standard "patch" program, "git apply" doesn't accept fuzz by default
> (which to me is a huge deal - I hate how "patch" tries to apply stuff
> that clearly isn't valid any more) and also knows about things like
> file modes and renames etc.

I've learned to use -F0, but yeah, that's a pain.

> 
> That second part is something not enough people use, and when I make
> patches and tar-balls I still generate the old-style non-rename
> patches etc for that reason. But basically the command is designed to
> also be used in non-git environments, so the "standard usage" is very
> much not the "involve git details" behavior.

I just find it funny to use git outside of a git environment. Perhaps
"git apply" should have another name? "pit"?

> 
> Most "true git" workflows end up using "git am" (or, better yet, "git
> pull" etc) to apply patches, which obviously not only does the --index
> thing, but also applies the changelog etc.

I'm still somewhat old school, and my workflow uses git + quilt a bit. I
do a bunch of changes, then I do:

git diff > foo.patch
patch -p1 -R < foo.patch
quilt import foo.patch
rm foo.patch

And save off those changes to another time. When I get back to the
patch, I do:

quilt push
<make final fixes>
quilt refresh
quilt pop
git apply --index < patches/foo.patch

Sometimes I just leave off the pop and apply to do a git commit -a, but
then when I do a quilt pop I need to do a "git reset --hard" to reset
things. Having the patch in quilt gives me a nice record of what I did,
instead of searching through git history.

Note, I do know about git quiltimport, but my quilt queue contains lots
of debug patches and things that are still pending (I modify the series
file a lot). What would help is to add an option to git quiltimport that
will limit the number of patches it imports.

git quiltimport -c 1

-- Steve


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