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

From: Junio C Hamano <junkio@cox.net>
Date: Aug 18, 2006, 09:43 UTC
Message-ID: <7virkqbcq3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060818084545.GB4717@diku.dk>

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 ;-).