Re: [RFC PATCHv2 1/2] am: add gitk patch format
Chris Packham judge.pack...@gmail.com writes: So teaching git mailinfo to do s/^// (either when asked to or using some heuristic) would be a better approach? I also think we should accept Author: as an acceptable fallback if From: is not present. Not as a fallback in the sense that Author: should not be treated any specially when am (which stands for apply mail) is operating on the patches in e-mails. Whatever wants to convert the output from log --pretty as if it came from log --pretty=email would certainly need to flip Author: to From: (what should happen when it sees From: in the input, though???), and whatgver wannts to pick metainfo from log --pretty output like mailinfo does for log --pretty=email output would certainly need to pick the authorship from Author: (without paying any attention to From: if one exists). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2 1/2] am: add gitk patch format
On Sat, Sep 6, 2014 at 6:29 AM, Junio C Hamano gits...@pobox.com wrote: Chris Packham judge.pack...@gmail.com writes: So teaching git mailinfo to do s/^// (either when asked to or using some heuristic) would be a better approach? I also think we should accept Author: as an acceptable fallback if From: is not present. Not as a fallback in the sense that Author: should not be treated any specially when am (which stands for apply mail) is\ operating on the patches in e-mails. I was proposing we avoid the Patch does not have a valid e-mail address. error when we can dwim and determine the email address from Author:. I originally was going to say From: should take precedence but it would be another way to indicate that the true author is not necessarily the person who sent the email. Whatever wants to convert the output from log --pretty as if it came from log --pretty=email would certainly need to flip Author: to From: (what should happen when it sees From: in the input, though???), and whatgver wannts to pick metainfo from log --pretty output like mailinfo does for log --pretty=email output would certainly need to pick the authorship from Author: (without paying any attention to From: if one exists). Wow. I didn't know --pretty=email existed. Better yet it works for diff-tree so gitk should probably be using that to produce something that can be exported/imported easily. I do wonder what the original use-case for write commit to file was. Once it's been written to a file what is one supposed to do with it? It's not something that 'git am' can consume (currently). Using 'git apply' or 'patch' would lose the commit message plus you have to manually stage/commit the changes. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2 1/2] am: add gitk patch format
Hi Junio, On Fri, Sep 5, 2014 at 5:21 AM, Junio C Hamano gits...@pobox.com wrote: Chris Packham judge.pack...@gmail.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2 1/2] am: add gitk patch format
(added back git ml because I accidentally dropped the Cc when replying to Junio). On Fri, Sep 5, 2014 at 10:57 AM, Junio C Hamano gits...@pobox.com wrote: 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. am uses mailsplit on the input file to separate it into one or more input files, each of which represents a single change. On each of them, it uses mailinfo to extract the meta information (e.g. authorship), log message and the patch into separate files. Except when --patch-format=hg|stgit is specified (or detected). In these cases mailsplit is avoided. It does not make any sense for a support for a new input format that does not teach mailinfo how to handle that format. Transforming it into a pseudo e-mail format is not the way to go. If that approach were acceptable, that format conversion filter can be run completely outside am in the first place, no? So teaching git mailinfo to do s/^// (either when asked to or using some heuristic) would be a better approach? I also think we should accept Author: as an acceptable fallback if From: is not present. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
