{"thread":{"id":"18485","subject":"[bug?] git-format-patch produces a 0-byte long patch for the first commit","startedAt":"2009-03-23T10:34:07Z","lastAt":"2009-03-26T17:29:25Z","messageCount":8,"participants":["Guennadi Liakhovetski","Thomas Rast","Jeff King","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"109033","messageId":"Pine.LNX.4.64.0903231119110.4871@axis700.grange","threadId":"18485","inReplyTo":null,"subject":"[bug?] git-format-patch produces a 0-byte long patch for the first commit","fromName":"Guennadi Liakhovetski","fromEmail":"g.liakhovetski@gmx.de","sentAt":"2009-03-23T10:34:07Z","receivedAt":"2009-03-23T10:34:07Z","isPatch":false,"sender":{"key":"g.liakhovetski@gmx.de","avatar":null},"body":"Hi,\n\nI noticed some special \"features\" of the first git commit, which seem at \nleast inconsistent to me, even though I've got some explanations on IRC.\n\nE.g., the sequence\n\nmkdir x\ncd x\ngit-init\necho hi > greating\ngit-commit -a\ngit-format-patch -1\n\nproduces a 0-byte long patch. git-format-patch HEAD^ produces an error, \nwhereas with more than one commit it produces tha last patch. Yes, I know \nabout \"--root\" and that it does allow to extract the very first commit.\n\nThanks\nGuennadi\n---\nGuennadi Liakhovetski, Ph.D.\nFreelance Open-Source Software Developer\n"},{"id":"109084","messageId":"200903231729.08216.trast@student.ethz.ch","threadId":"18485","inReplyTo":"Pine.LNX.4.64.0903231119110.4871@axis700.grange","subject":"Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-03-23T16:29:03Z","receivedAt":"2009-03-23T16:29:03Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Guennadi Liakhovetski wrote:\n> mkdir x\n> cd x\n> git-init\n> echo hi > greating\n> git-commit -a\n[...]\n> git-format-patch HEAD^ produces an error, \n\nThere is no HEAD^ in this case. HEAD is always the currently checked\nout commit. Since it has a root commit, it has no parent, so you\ncannot apply ^ (\"the first parent of\") to it. Similarly, HEAD~2 will\nnot work if HEAD~1 has no parent, etc.\n\n> git-format-patch -1 produces a 0-byte long patch.\n\nThat is admittedly weird and probably deserves a fix and/or suggestion\nto use --root.\n\nI'm not sure what else I can add to the explanations I gave on IRC.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"109089","messageId":"Pine.LNX.4.64.0903231732150.6370@axis700.grange","threadId":"18485","inReplyTo":"200903231729.08216.trast@student.ethz.ch","subject":"Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit","fromName":"Guennadi Liakhovetski","fromEmail":"g.liakhovetski@gmx.de","sentAt":"2009-03-23T16:46:46Z","receivedAt":"2009-03-23T16:46:46Z","isPatch":false,"sender":{"key":"g.liakhovetski@gmx.de","avatar":null},"body":"On Mon, 23 Mar 2009, Thomas Rast wrote:\n\n> Guennadi Liakhovetski wrote:\n> > mkdir x\n> > cd x\n> > git-init\n> > echo hi > greating\n> > git-commit -a\n> [...]\n> > git-format-patch HEAD^ produces an error, \n> \n> There is no HEAD^ in this case. HEAD is always the currently checked\n> out commit. Since it has a root commit, it has no parent, so you\n> cannot apply ^ (\"the first parent of\") to it. Similarly, HEAD~2 will\n> not work if HEAD~1 has no parent, etc.\n\nYes, I can understand this, still from the high-level PoV, this looks \ninconsistent:\n\ngit-format-patch HEAD\n\nnever produces anything, which means for me, I'm trying to extract commits \nfor a 0-length range.\n\ngit-format-patch HEAD^\n\nUsually produces the \"current\" or the \"last\" commit - except if you're \ncurrently on the first commit... But I'm not insisting on this one - maybe \nyou're right, it just _does_ look weird.\n\nJust try to forget about the meaning of the command. You are somewhere on \nthe commit timeline. You enter \"some\" command, which usually produces \nexactly one - the most recent commit. So, I would expect this to work \nalways when there is at least one commit in the tree.\n\nSo, maybe it would make sense to refer to the point before-the-root-commit \nevery time root's parent is requested?\n\n> > git-format-patch -1 produces a 0-byte long patch.\n> \n> That is admittedly weird and probably deserves a fix and/or suggestion\n> to use --root.\n> \n> I'm not sure what else I can add to the explanations I gave on IRC.\n\nThanks for answering again, I just wanted to make sure this \"weirdness\" \ndoesn't get lost, and possibly gets fixed. I think, you suggested yourself \nto post to the list, so I did.\n\nThanks\nGuennadi\n---\nGuennadi Liakhovetski, Ph.D.\nFreelance Open-Source Software Developer\n"},{"id":"109164","messageId":"20090324075424.GC32400@coredump.intra.peff.net","threadId":"18485","inReplyTo":"Pine.LNX.4.64.0903231119110.4871@axis700.grange","subject":"Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-24T07:54:24Z","receivedAt":"2009-03-24T07:54:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:\n\n> mkdir x\n> cd x\n> git-init\n> echo hi > greating\n> git-commit -a\n> git-format-patch -1\n> \n> produces a 0-byte long patch. git-format-patch HEAD^ produces an error, \n> whereas with more than one commit it produces tha last patch. Yes, I know \n> about \"--root\" and that it does allow to extract the very first commit.\n\nWhat version of git are you using? I believe the 0-byte diff has been\nfixed since git 1.6.1.1.\n\n-Peff\n"},{"id":"109166","messageId":"Pine.LNX.4.64.0903240901570.4451@axis700.grange","threadId":"18485","inReplyTo":"20090324075424.GC32400@coredump.intra.peff.net","subject":"Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit","fromName":"Guennadi Liakhovetski","fromEmail":"g.liakhovetski@gmx.de","sentAt":"2009-03-24T08:02:43Z","receivedAt":"2009-03-24T08:02:43Z","isPatch":false,"sender":{"key":"g.liakhovetski@gmx.de","avatar":null},"body":"On Tue, 24 Mar 2009, Jeff King wrote:\n\n> On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:\n> \n> > mkdir x\n> > cd x\n> > git-init\n> > echo hi > greating\n> > git-commit -a\n> > git-format-patch -1\n> > \n> > produces a 0-byte long patch. git-format-patch HEAD^ produces an error, \n> > whereas with more than one commit it produces tha last patch. Yes, I know \n> > about \"--root\" and that it does allow to extract the very first commit.\n> \n> What version of git are you using? I believe the 0-byte diff has been\n> fixed since git 1.6.1.1.\n\nMine is still 1.5.4, if it's already fixed in the meantime - all the \nbetter!\n\nThanks\nGuennadi\n---\nGuennadi Liakhovetski, Ph.D.\nFreelance Open-Source Software Developer\n"},{"id":"109206","messageId":"alpine.DEB.1.00.0903241244380.7493@intel-tinevez-2-302","threadId":"18485","inReplyTo":"Pine.LNX.4.64.0903240901570.4451@axis700.grange","subject":"Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-24T11:46:28Z","receivedAt":"2009-03-24T11:46:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Mar 2009, Guennadi Liakhovetski wrote:\n\n> On Tue, 24 Mar 2009, Jeff King wrote:\n> \n> > On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:\n> > \n> > > mkdir x\n> > > cd x\n> > > git-init\n> > > echo hi > greating\n> > > git-commit -a\n> > > git-format-patch -1\n> > > \n> > > produces a 0-byte long patch. git-format-patch HEAD^ produces an \n> > > error, whereas with more than one commit it produces tha last patch. \n> > > Yes, I know about \"--root\" and that it does allow to extract the \n> > > very first commit.\n> > \n> > What version of git are you using? I believe the 0-byte diff has been \n> > fixed since git 1.6.1.1.\n> \n> Mine is still 1.5.4, if it's already fixed in the meantime - all the \n> better!\n\nThere is the off-chance that somewhere in those 3127 commits between \nv1.5.4 and v1.6.1.1, not only this bug is fixed. You might be surprised \n;-)\n\nSeriously again, in a project that moves as fast as Git, you should always \ntest with a recent version, and v1.5.1 -- being over one year old -- does \nnot account for recent.\n\nCiao,\nDscho\n"},{"id":"109207","messageId":"Pine.LNX.4.64.0903241250140.4451@axis700.grange","threadId":"18485","inReplyTo":"alpine.DEB.1.00.0903241244380.7493@intel-tinevez-2-302","subject":"Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit","fromName":"Guennadi Liakhovetski","fromEmail":"g.liakhovetski@gmx.de","sentAt":"2009-03-24T11:51:08Z","receivedAt":"2009-03-24T11:51:08Z","isPatch":false,"sender":{"key":"g.liakhovetski@gmx.de","avatar":null},"body":"On Tue, 24 Mar 2009, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Tue, 24 Mar 2009, Guennadi Liakhovetski wrote:\n> \n> > On Tue, 24 Mar 2009, Jeff King wrote:\n> > \n> > > On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:\n> > > \n> > > > mkdir x\n> > > > cd x\n> > > > git-init\n> > > > echo hi > greating\n> > > > git-commit -a\n> > > > git-format-patch -1\n> > > > \n> > > > produces a 0-byte long patch. git-format-patch HEAD^ produces an \n> > > > error, whereas with more than one commit it produces tha last patch. \n> > > > Yes, I know about \"--root\" and that it does allow to extract the \n> > > > very first commit.\n> > > \n> > > What version of git are you using? I believe the 0-byte diff has been \n> > > fixed since git 1.6.1.1.\n> > \n> > Mine is still 1.5.4, if it's already fixed in the meantime - all the \n> > better!\n> \n> There is the off-chance that somewhere in those 3127 commits between \n> v1.5.4 and v1.6.1.1, not only this bug is fixed. You might be surprised \n> ;-)\n> \n> Seriously again, in a project that moves as fast as Git, you should always \n> test with a recent version, and v1.5.1 -- being over one year old -- does \n> not account for recent.\n\nSorry, didn't mention, I also tested with 1.6.0.6 - still was there.\n\nThanks\nGuennadi\n---\nGuennadi Liakhovetski, Ph.D.\nFreelance Open-Source Software Developer\n"},{"id":"109572","messageId":"af6ac91054a35020e3cc4c9242f82cc96714ea7c.1238086612.git.trast@student.ethz.ch","threadId":"18485","inReplyTo":"Pine.LNX.4.64.0903231732150.6370@axis700.grange","subject":"[PATCH] Documentation: format-patch --root clarifications","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-03-26T17:29:25Z","receivedAt":"2009-03-26T17:29:25Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Users were confused about the meaning and use of the --root option.\nNotably, since 68c2ec7 (format-patch: show patch text for the root\ncommit, 2009-01-10), --root has nothing to do with showing the patch\ntext for the root commit any more.\n\nShorten and clarify the corresponding paragraph in the DESCRIPTION\nsection, document --root under OPTIONS, and add an explicit note that\nroot commits are formatted regardless.\n\nSigned-off-by: Thomas Rast \n---\n\nGuennadi Liakhovetski wrote:\n> On Mon, 23 Mar 2009, Thomas Rast wrote:\n> \n> > > git-format-patch -1 produces a 0-byte long patch.\n> > \n> > That is admittedly weird and probably deserves a fix and/or suggestion\n> > to use --root.\n\nI finally got around to looking at this again. The 0-byte patch issue\nis fixed since 1.6.2 (68c2ec7 mentioned above), so the above no longer\napplies. The patch merely tries to make this clearer in the\ndocumentation.\n\n> Yes, I can understand this, still from the high-level PoV, this looks \n> inconsistent:\n> \n> git-format-patch HEAD\n> \n> never produces anything, which means for me, I'm trying to extract commits \n> for a 0-length range.\n> \n> git-format-patch HEAD^\n> \n> Usually produces the \"current\" or the \"last\" commit - except if you're \n> currently on the first commit... But I'm not insisting on this one - maybe \n> you're right, it just _does_ look weird.\n>\n> Just try to forget about the meaning of the command. You are somewhere on \n> the commit timeline. You enter \"some\" command, which usually produces \n> exactly one - the most recent commit. So, I would expect this to work \n> always when there is at least one commit in the tree.\n\nIt's not like this is voodoo, the problem is that you're reading a\ndifferent meaning into the observable behaviour than what the revision\nwalker does.\n\nFirst, note that rule 1 in the git-format-patch manpage simply states\nthat specifying a single is equivalent to specifying the\nrange '..', i.e., '..HEAD'.\n\nWith that out of the way, turn to man git-rev-list and note that\n'..HEAD' is another way of spelling '^ HEAD'. Which\nmeans to list all commits that are reachable from HEAD, but not\n. Thus, in *linear* history, 'HEAD^..' always means the\ncurrent commit, but that's just a special case. If you're on a merge\ncommit, 'HEAD^..' only excludes commits reachable from the *first*\nparent of the merge, so (unless the merge was trivial) this range\nactually contains more than one commit.\n\nAnd it should become clearer that in order to reach (and thus\ninclude/exclude) anything, both ends of the revision range must\nexist. So if there is no parent of the current commit (i.e., it is a\nroot), you cannot use the HEAD^ syntax.\n\nAdmittedly, the special handling of in git-format-patch\ndiffers from all(?) other revision walking commands (log, rev-list,\nbundle, fast-export).\n\n\n Documentation/git-format-patch.txt | 21 ++++++++++++---------\n 1 files changed, 12 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex c2eb5fa..c105925 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -40,15 +40,11 @@ There are two ways to specify which commits to operate on.\n REVISIONS\" section in linkgit:git-rev-parse[1]) means the\n commits in the specified range.\n \n-A single commit, when interpreted as a \n-expression, means \"everything that leads to that commit\", but\n-if you write 'git format-patch ', the previous rule\n-applies to that command line and you do not get \"everything\n-since the beginning of the time\". If you want to format\n-everything since project inception to one commit, say \"git\n-format-patch \\--root \" to make it clear that it is the\n-latter case. If you want to format a single commit, you can do\n-this with \"git format-patch -1 \".\n+The first rule takes precedence in the case of a single . To\n+apply the second rule, i.e., format everything since the beginning of\n+history up until , use the '\\--root' option: \"git format-patch\n+\\--root \". If you want to format only itself, you\n+can do this with \"git format-patch -1 \".\n \n By default, each output file is numbered sequentially from 1, and uses the\n first line of the commit message (massaged for pathname safety) as\n@@ -182,6 +178,13 @@ not add any suffix.\n \tapplied. By default the contents of changes in those files are\n \tencoded in the patch.\n \n+--root::\n+\tTreat the revision argument as a , even if it\n+\tis just a single commit (that would normally be treated as a\n+\t). Note that root commits included in the specified\n+\trange are always formatted as creation patches, independently\n+\tof this flag.\n+\n CONFIGURATION\n -------------\n You can specify extra mail header lines to be added to each message\n-- \n1.6.2.1.558.ge131\n"}]}