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.
- "git apply" is actually also designed to be a *replacement* for
"patch". In particular, you can use it outside a git repository,
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.
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.
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.
Linus
--
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/
