Re: [PATCH] git-apply: document remaining options in the man page

[Junio C Hamano <junkio@cox.net>]

Jonas Fonseca <fonseca@diku.dk> writes:

> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> ---
>
> [ On top of next if that matters. ]

I'd appreciate if you can hold this off for a while; I'll be
updating git-apply a bit further, to add --verbose ("patching
foo...", "rejected hunk #4", etc.) and perhaps --clobber (apply
to working tree files that have local modifications), together
with --reject (apply hunks that could, while leaving
unapplicable ones out).  I've been reluctant to spray .rej files
all over the tree and was planning to spit all into a single
stream (stdout), which is what is on "pu" now, but I changed my
mind and decided to mimic what other people do (that format is
more useful to work with because other tools like wiggle expect
.rej files next to the target files).

> I'm not sure if I got the --exclude note right, which says that running
> apply from a subdirectory automatically excludes files outside the
> subdirectory.

I was thinking about dropping the exclude altogether, actually.

Also I've never thought about the possibility of anybody running
git-apply from a subdirectory.  git diffs by design always come
with full paths from the project toplevel, so I simply had a
preconception that everybody understood that applying would also
be always from the toplevel.

Don't get me wrong -- I do not mean to say that running apply
from a subdirectory is wrong.  I just haven't thought about
doing so, and need to think the implications through.

> Lastly, `log -S<option>` is so great when doing these man pages updates
> and you, like me, don't know the code very well, since you can "just"
> paraphrase the commit message that will sometimes also describe the
> scenario where the option is applicable. :)

Praise pickaxe, and say no to annotate ;-).