{"thread":{"id":"18021","subject":"serious problem with `git format-patch' & `git am'","startedAt":"2009-02-25T22:03:52Z","lastAt":"2009-02-27T17:53:50Z","messageCount":8,"participants":["Werner LEMBERG","Johannes Schindelin","Brandon Casey","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"106267","messageId":"20090225.230352.177616203.wl@gnu.org","threadId":"18021","inReplyTo":null,"subject":"serious problem with `git format-patch' & `git am'","fromName":"Werner LEMBERG","fromEmail":"wl@gnu.org","sentAt":"2009-02-25T22:03:52Z","receivedAt":"2009-02-25T22:03:52Z","isPatch":false,"sender":{"key":"wl@gnu.org","avatar":null},"body":"\n[both version 1.6.0.2 and git from 2009-01-24]\n\nFolks,\n\n\nI'm going to convert the FreeType CVS repository to git, using Keith\nPackard's `parsecvs'. It sometimes happens that there are git entries\ntitled\n\n *** empty log message ***\n\nI want to massage the git repository before publishing it, replacing\nthose entries with something more meaningful.\n\nThe last time I tested this (using git 1.5.something, I no longer\nremember the exact version) I did the following:\n\n . git format-patch ..HEAD\n git reset --hard \n\n . Edit the `Subject:' field in the created *.patch files where\n necessary.\n\n . git am --whitespace=nowarn *.patch\n\nUnfortunately, this no longer works as before, and since I can't find\na hint in the docs about this change I wonder whether it is a bug.\n\nWith git 1.5.something, if the first paragraph of the commit message\n(as output by parsecvs) looks like this\n\n foo foo foo foo\n bar bar bar bar\n baz baz baz baz\n\nit is emitted exactly as-is (after `git format-patch' & `git am');\ngitk shows `foo foo foo foo' as the first line. However, git version\n1.6.0.2 and the current git both convert newlines to spaces in the\nfirst paragraph! I now get\n\n foo foo foo foo bar bar bar bar baz baz baz baz\n\nas the beginning of the commit message which is VERY bad since\nCVS-style entries often have a long first paragraph, causing\nugly-looking, overlong lines.\n\nIn case this is an intended change I ask you urgently to provide an\noption to get back the old behaviour of `git format-patch' & `git am'.\n\n\n Werner\n"},{"id":"106313","messageId":"alpine.DEB.1.00.0902261138260.6258@intel-tinevez-2-302","threadId":"18021","inReplyTo":"20090225.230352.177616203.wl@gnu.org","subject":"Re: serious problem with `git format-patch' & `git am'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-26T10:42:18Z","receivedAt":"2009-02-26T10:42:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[welcome on the Git list, Werner!]\n\nOn Wed, 25 Feb 2009, Werner LEMBERG wrote:\n\n> \n> [both version 1.6.0.2 and git from 2009-01-24]\n> \n> Folks,\n> \n> \n> I'm going to convert the FreeType CVS repository to git, using Keith\n> Packard's `parsecvs'. It sometimes happens that there are git entries\n> titled\n> \n> *** empty log message ***\n> \n> I want to massage the git repository before publishing it, replacing\n> those entries with something more meaningful.\n> \n> The last time I tested this (using git 1.5.something, I no longer\n> remember the exact version) I did the following:\n> \n> . git format-patch ..HEAD\n> git reset --hard \n> \n> . Edit the `Subject:' field in the created *.patch files where\n> necessary.\n> \n> . git am --whitespace=nowarn *.patch\n> \n> Unfortunately, this no longer works as before, and since I can't find\n> a hint in the docs about this change I wonder whether it is a bug.\n> \n> With git 1.5.something, if the first paragraph of the commit message\n> (as output by parsecvs) looks like this\n> \n> foo foo foo foo\n> bar bar bar bar\n> baz baz baz baz\n> \n> it is emitted exactly as-is (after `git format-patch' & `git am');\n> gitk shows `foo foo foo foo' as the first line. However, git version\n> 1.6.0.2 and the current git both convert newlines to spaces in the\n> first paragraph! I now get\n> \n> foo foo foo foo bar bar bar bar baz baz baz baz\n> \n> as the beginning of the commit message which is VERY bad since\n> CVS-style entries often have a long first paragraph, causing\n> ugly-looking, overlong lines.\n> \n> In case this is an intended change I ask you urgently to provide an\n> option to get back the old behaviour of `git format-patch' & `git am'.\n\nIt is an intended change, for the _opposite_ case: some people thrive on \noverly-long subject lines, and the change was supposed to help them.\n\nI was not sure if it would be a good change back then, but I did not have \nanything concrete I could present as an example where the behavior hurts.\n\nIn your case, I suggest using something different, though. Either use \n\"rebase -i\" and mark the commits you want to massage as \"edit\", or use \n\"fast-export > dump\", edit \"dump\" by hand, and then reimport the whole \nthing using fast-import.\n\nIMHO your use case is not a good candidate for format-patch, as that \nprogram was really meant for patch submission (even if it also serves \nother purposes pretty well).\n\nCiao,\nDscho\n"},{"id":"106347","messageId":"6HVVE8kW9V0CsNfW21a_Tqpt2s-IrJbt2_qdAvQ8r1tetEhb6jr18g@cipher.nrlssc.navy.mil","threadId":"18021","inReplyTo":"20090225.230352.177616203.wl@gnu.org","subject":"Re: serious problem with `git format-patch' & `git am'","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2009-02-26T18:00:16Z","receivedAt":"2009-02-26T18:00:16Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Werner LEMBERG wrote:\n> [both version 1.6.0.2 and git from 2009-01-24]\n> \n> Folks,\n> \n> \n> I'm going to convert the FreeType CVS repository to git, using Keith\n> Packard's `parsecvs'. It sometimes happens that there are git entries\n> titled\n> \n> *** empty log message ***\n> \n> I want to massage the git repository before publishing it, replacing\n> those entries with something more meaningful.\n> \n> The last time I tested this (using git 1.5.something, I no longer\n> remember the exact version) I did the following:\n> \n> . git format-patch ..HEAD\n> git reset --hard \n> \n> . Edit the `Subject:' field in the created *.patch files where\n> necessary.\n> \n> . git am --whitespace=nowarn *.patch\n> \n> Unfortunately, this no longer works as before, and since I can't find\n> a hint in the docs about this change I wonder whether it is a bug.\n> \n> With git 1.5.something, if the first paragraph of the commit message\n> (as output by parsecvs) looks like this\n> \n> foo foo foo foo\n> bar bar bar bar\n> baz baz baz baz\n> \n> it is emitted exactly as-is (after `git format-patch' & `git am');\n> gitk shows `foo foo foo foo' as the first line. However, git version\n> 1.6.0.2 and the current git both convert newlines to spaces in the\n> first paragraph! I now get\n> \n> foo foo foo foo bar bar bar bar baz baz baz baz\n> \n> as the beginning of the commit message which is VERY bad since\n> CVS-style entries often have a long first paragraph, causing\n> ugly-looking, overlong lines.\n> \n> In case this is an intended change I ask you urgently to provide an\n> option to get back the old behaviour of `git format-patch' & `git am'.\n\nI was not aware of this behavior, but it looks like the '-k' option for\nboth format-patch and git-am is what you want to use. It will prevent\nmailinfo from munging the commit message.\n\n-brandon\n"},{"id":"106388","messageId":"m3ljrsvg0e.fsf@localhost.localdomain","threadId":"18021","inReplyTo":"6HVVE8kW9V0CsNfW21a_Tqpt2s-IrJbt2_qdAvQ8r1tetEhb6jr18g@cipher.nrlssc.navy.mil","subject":"Re: serious problem with `git format-patch' & `git am'","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-02-27T01:11:45Z","receivedAt":"2009-02-27T01:11:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Brandon Casey writes:\n> Werner LEMBERG wrote:\n> > [both version 1.6.0.2 and git from 2009-01-24]\n> >\n> > I'm going to convert the FreeType CVS repository to git, using Keith\n> > Packard's `parsecvs'.\n\n>From what I understand it is not maintained, is not incremental, and\nrequires access to *,v files. Why not use more modern and actively\ndeveloped cvs2git tool from cvs2svn project[1]?\n\n[1] http://cvs2svn.tigris.org\n[2] http://git.or.cz/gitwiki/InterfacesFrontendsAndTools\n \"Interaction with other Revision Control Systems\" section\n\n> > It sometimes happens that there are git entries\n> > titled\n> > \n> > *** empty log message ***\n> > \n> > I want to massage the git repository before publishing it, replacing\n> > those entries with something more meaningful.\n> > \n> > The last time I tested this (using git 1.5.something, I no longer\n> > remember the exact version) I did the following:\n> > \n> > . git format-patch ..HEAD\n> > git reset --hard \n> > \n> > . Edit the `Subject:' field in the created *.patch files where\n> > necessary.\n> > \n> > . git am --whitespace=nowarn *.patch\n\nYou can use the following alternate solutions:\n\n * git rebase --interactive (perhaps with --root option if your git\n supports it, or cherry-pick root commit by hand if it does not),\n changing 'pick' to 'edit' for patches (commits) that you want to\n modify commit message.\n\n * if you can automate the changes, i.e. if you can script it, the\n best solution would be to use git-filter-branch instead; or use\n fast-export / fast-import pair with your filter in the middle.\n\n> > \n> > Unfortunately, this no longer works as before, and since I can't find\n> > a hint in the docs about this change I wonder whether it is a bug.\n> > \n> > With git 1.5.something, if the first paragraph of the commit message\n> > (as output by parsecvs) looks like this\n> > \n> > foo foo foo foo\n> > bar bar bar bar\n> > baz baz baz baz\n> > \n> > it is emitted exactly as-is (after `git format-patch' & `git am');\n> > gitk shows `foo foo foo foo' as the first line. However, git version\n> > 1.6.0.2 and the current git both convert newlines to spaces in the\n> > first paragraph! I now get\n> > \n> > foo foo foo foo bar bar bar bar baz baz baz baz\n> > \n> > as the beginning of the commit message which is VERY bad since\n> > CVS-style entries often have a long first paragraph, causing\n> > ugly-looking, overlong lines.\n\nThis is caused by the fact that git-am assumes that subject line goes\nas first line of commit message, with empty line separating it from\nthe rest of commit message which comes from the body of email.\n\nIt used to preserve line breaking in Subject: line, if it was broken\ninto lines using continuation style for email headers, but that was\nwrong solution in the intended use case (applying patches from email,\npatches conforming to git commit message conventions), as Subject:\nline could have been broken into multiple lines by the _transport_\nlayer, and not intended to be broken.\n\n> > \n> > In case this is an intended change I ask you urgently to provide an\n> > option to get back the old behaviour of `git format-patch' & `git am'.\n> \n> I was not aware of this behavior, but it looks like the '-k' option for\n> both format-patch and git-am is what you want to use. It will prevent\n> mailinfo from munging the commit message.\n\nI think you want undocumented but for the git-am usage (e.g. 'git am\n-h') --rebasing option to git-am, which makes git-am preserve Subject:\nline formatting, _including_ line breaking (I think that -k/--keep\ndoes preserve subject, but does not preserve line breaking; I haven't\nchecked this, though). Note that in this case you would have to make\ngit-format-patch to not output subject prefix ([PATCH]).\n\nSee how git-rebase.sh does it.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"106389","messageId":"7viqmwpr2x.fsf@gitster.siamese.dyndns.org","threadId":"18021","inReplyTo":"m3ljrsvg0e.fsf@localhost.localdomain","subject":"Re: serious problem with `git format-patch' & `git am'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-27T02:10:46Z","receivedAt":"2009-02-27T02:10:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> I think you want undocumented but for the git-am usage (e.g. 'git am\n> -h') --rebasing option to git-am, which makes git-am preserve Subject:\n> line formatting,...\n\nI have to warn that that one requires you to have proper commit object\nto begin with. IOW, the first line \"From [0-9a-f]{40} date\" must record\nan existing object name.\n\nAs you said, \"am\" is for applying e-mailed patches and filter-branch would\nbe the best fit for fixing imported history, but whichever tool is used, I\nthink it is a mistake to try preserving a \"one-line-per-paragraph\" format\nthe original poster seems to have, i.e.:\n\n foo foo foo foo\n bar bar bar bar\n baz baz baz baz\n\nYes, the low-level could create a commit object with a message like that,\nbut all the Porcelains rely on \"paragraphs are separated with a blank\nline\" format. So no matter how the conversion is done, I think it would\nbe a good idea to turn the above into:\n\n foo foo foo foo\n\n bar bar bar bar\n baz baz baz baz\n\nif the user wants to keep the resulting history any useful.\n\nTo do it with \"format-patch | am\", you would format it like:\n\n\tSubject: foo foo foo foo\n From: author name \n Date: author date\n\n bar bar bar bar\n baz baz baz baz\n\n \n"},{"id":"106414","messageId":"20090227.101649.156177765.wl@gnu.org","threadId":"18021","inReplyTo":"6HVVE8kW9V0CsNfW21a_Tqpt2s-IrJbt2_qdAvQ8r1tetEhb6jr18g@cipher.nrlssc.navy.mil","subject":"Re: serious problem with `git format-patch' & `git am'","fromName":"Werner LEMBERG","fromEmail":"wl@gnu.org","sentAt":"2009-02-27T09:16:49Z","receivedAt":"2009-02-27T09:16:49Z","isPatch":false,"sender":{"key":"wl@gnu.org","avatar":null},"body":"\n> I was not aware of this behavior, but it looks like the '-k' option\n> for both format-patch and git-am is what you want to use. It will\n> prevent mailinfo from munging the commit message.\n\nTried it already. It doesn't help.\n\n\n Werner\n"},{"id":"106441","messageId":"zE3C931NyNaTaadZOgAI_rGf6gmkKr-3ZHRVXh87mHpCMs-0hfnhYg@cipher.nrlssc.navy.mil","threadId":"18021","inReplyTo":"7viqmwpr2x.fsf@gitster.siamese.dyndns.org","subject":"Re: serious problem with `git format-patch' & `git am'","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2009-02-27T15:47:49Z","receivedAt":"2009-02-27T15:47:49Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"\nJunio,\n\nI think you are the author of git-am.sh.\n\nWhat does this line do?\n\ngit-am.sh line 375:\n\n case \"$keep_subject\" in -k) SUBJECT=\"[PATCH] $SUBJECT\" ;; esac\n\nIt appears to do nothing. It has existed since the beginning of git-am.sh,\nand there has never been another reference to $keep_subject in this script.\nIs it possible that $keep_subject is supposed to be $keep?\n\n-brandon\n"},{"id":"106452","messageId":"7vr61jkbpt.fsf@gitster.siamese.dyndns.org","threadId":"18021","inReplyTo":"zE3C931NyNaTaadZOgAI_rGf6gmkKr-3ZHRVXh87mHpCMs-0hfnhYg@cipher.nrlssc.navy.mil","subject":"Re: serious problem with `git format-patch' & `git am'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-27T17:53:50Z","receivedAt":"2009-02-27T17:53:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey writes:\n\n> What does this line do?\n>\n> git-am.sh line 375:\n>\n> case \"$keep_subject\" in -k) SUBJECT=\"[PATCH] $SUBJECT\" ;; esac\n>\n> It appears to do nothing. It has existed since the beginning of git-am.sh,\n> and there has never been another reference to $keep_subject in this script.\n> Is it possible that $keep_subject is supposed to be $keep?\n\nI do not think it is doing anything, and I do not think it makes sense to\n\"fix\" it to allow adding \"[PATCH] \" in front either. I'd vote for\nremoving the entire thing.\n\nThe $keep_subject variable and \"add [PATCH] only to later strip\" logic was\nborrowed from git-applymbox and git-applypatch pair, see 6bff6a6 (Teach\napplymbox to keep the Subject: line., 2005-08-16) especially for the\nchange that affects tools/git-applypatch in the commit. I think there was\na reason that -k refrained from adding the prefix in git-applypatch but\nthe option to git-am needed to add the prefix which seems inconsistent but\nI do not recall the details. Maybe the list archive may know.\n"}]}