Hi Junio, On Fri, Sep 5, 2014 at 5:21 AM, Junio C Hamano <[email protected]> wrote: > Chris Packham <[email protected]> writes: > >> Another thing that I've since realised is that this 'gitk' format is >> also what you've get from git show or git log -p. So this is actually >> allowing (for better or worse) things like 'git show $sha1 | git am >> --patch-format=gitk'[*1*]. That may mean that we should call the >> format something else ("pretty" perhaps?) and note that this is what >> gitk, git show and some incantations of git log generate. > > I would not call it "pretty", because "--pretty" is merely a > short-hand to "--pretty=<some format name>". > > The output format indents the log message text by four spaces for > human reading to make it stand out from the patch text, and not > meant for machine consumption.
Fair enough. > I doubt that a patchset that does > not update mailinfo and mailsplit to extract information and to undo > the indentation could be a right solution. I've read this sentence a couple of times and I can't understand it. I get that you are against adding yet more special cases to 'git am' to handle patches that weren't generated by 'git format-patch'. Are you saying that this won't go in or that the solution should be implemented differently. > "am" itself should not > be mucking with the input files. > At the very least we need to drop the first line and replace "Author" with "From". Which would still leave the commit message indented. Something like the following allows the patch to be applied sed -e '1d' -e 's/^Author:/From:/' <patch.patch | git am But it'd be nice if am could do that for me to save my fingers some work. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
