On Wed, 2013-07-24 at 10:24 -0700, Linus Torvalds wrote: > On Wed, Jul 24, 2013 at 10:16 AM, Steven Rostedt <rost...@goodmis.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
