From: Chris Packham Date: Thu, 04 Sep 2014 22:47:39 GMT Subject: Re: [RFC PATCHv2 1/2] am: add gitk patch format Message-ID: In-Reply-To: Hi Junio, On Fri, Sep 5, 2014 at 5:21 AM, Junio C Hamano wrote: > Chris Packham 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=". > > 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:/'