{"thread":{"id":"4293","subject":"git-format-patch possible regressions","startedAt":"2006-05-25T19:23:23Z","lastAt":"2006-05-28T09:57:18Z","messageCount":14,"participants":["Marco Costalba","Linus Torvalds","Junio C Hamano","Johannes Schindelin","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"20698","messageId":"e5bfff550605251223g2cf8cfb9vfa18d016b369188d@mail.gmail.com","threadId":"4293","inReplyTo":null,"subject":"git-format-patch possible regressions","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-05-25T19:23:23Z","receivedAt":"2006-05-25T19:23:23Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"A couple of possible regressions:\n\n1) Unreconized --signoff option\n\n$ git --version\ngit version 1.3.3.ged90\n$ git-format-patch -s HEAD^..HEAD\n0001-cat-file-document-p-option.txt\n$ git-format-patch --signoff HEAD^..HEAD\nfatal: unrecognized argument: --signoff\n\n\n2) Unhandled ranges list\n\n$ git --version\ngit version 1.3.3.ged90\n$ git-format-patch -s HEAD^..HEAD HEAD^^..HEAD^\n0001-cat-file-document-p-option.txt\n\n$ git --version\ngit version 1.3.3.gf205\ngit checkout -b test 51ce34b9923d9b119ac53414584f80e05520abea\n$ git-format-patch HEAD^..HEAD HEAD^^..HEAD^\n0001-Builtin-git-show-branch.txt\n0002-Builtin-git-apply.txt\n\nBoth regressions brake qgit. The first one is easy to fix (--signoff --> -s)\nThe second one is not so easy.\nIt is use to format a patch series starting from a mouse selected\nmultiple revisions. Note that the revisions could be not consecutive.\nNote also that looping git-format-patch for each revision does not\nupdates patch number that always stay at 0001.\n\nFeeding all the selected revisions in one go in the form\ngit-format-patch sel1^..sel1 sel2^..sel2 ........ seln^..seln is\nthe only way I have found to:\n\n1) create a patch series of (randomly) selected revisions\n\n2) increment patch numbers for each patch\n\n\n Marco\n"},{"id":"20699","messageId":"Pine.LNX.4.64.0605251233300.5623@g5.osdl.org","threadId":"4293","inReplyTo":"e5bfff550605251223g2cf8cfb9vfa18d016b369188d@mail.gmail.com","subject":"Re: git-format-patch possible regressions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-25T19:43:29Z","receivedAt":"2006-05-25T19:43:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 25 May 2006, Marco Costalba wrote:\n> \n> 2) Unhandled ranges list\n> \n> $ git-format-patch -s HEAD^..HEAD HEAD^^..HEAD^\n\nYou _really_ shouldn't use this \"mix two ranges\" format.\n\nIt may have \"worked\" before, but it\n - worked differently from all other git ranges\n - it was really an implementation detail (handling each argument \n separately)\n\nThe \"x..y\" format is defined to mean the same thing \"y ^x\", and that means \nthat \"HEAD^..HEAD HEAD^^..HEAD^\" really does mean the same thing as \n\"^HEAD^ ^HEAD^^ HEAD HEAD^\", which in turn means the same thing as \"^HEAD^ \nHEAD\" from a reachability standpoint (since HEAD^ is by definition \nreachable from HEAD, adding it won't change the revision list, and the \nsame goes for ^HEAD^^ vs ^HEAD^).\n\nSo thus \"HEAD^..HEAD HEAD^^..HEAD^\" really _is_ the same thing as \n\"HEAD^..HEAD\", and any tool that thought otherwise was just being \nvery confused.\n\nNow, we could choose to try to make \"a..b\" mean something else (ie make \nthe \"^a\" part only meaningful for that particular \"sub-query\"), and yes, \nin many ways that would be a more intuitive thing, but it's not how git \nrevision descriptions work currently, and if we make that change we should \ndo it across the board.\n\n(It's not an easy change to make, but it should be possible by having \nmultiple separate NECESSARY/UNNECESSARY bits, and make the revision \nwalking logic a whole lot more complicated than it already is).\n\nSo I'd argue that you should really do something like\n\n\t( git-rev-list a..b ; git-rev-list c..d ) |\n\t\tgit-format-patch --stdin\n\nin qgit if you want the ranges to be truly independent.\n\n(And no, I don't think git-format-patch takes a \"--stdin\" argument, but it \nmight not be unreasonable to add it as a generic revision walking \nargument for scripting like this).\n\n\t\t\tLinus\n"},{"id":"20700","messageId":"7vhd3dubd9.fsf@assigned-by-dhcp.cox.net","threadId":"4293","inReplyTo":"e5bfff550605251223g2cf8cfb9vfa18d016b369188d@mail.gmail.com","subject":"Re: git-format-patch possible regressions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-25T19:56:34Z","receivedAt":"2006-05-25T19:56:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> A couple of possible regressions:\n>\n> 1) Unreconized --signoff option\n>\n> $ git --version\n> git version 1.3.3.ged90\n> $ git-format-patch -s HEAD^..HEAD\n> 0001-cat-file-document-p-option.txt\n> $ git-format-patch --signoff HEAD^..HEAD\n> fatal: unrecognized argument: --signoff\n>...\n> Both regressions brake qgit. The first one is easy to fix (--signoff --> -s)\n\nI do not think -s does what you want. It means \"do not generate\ndiff\" to the diff family, but format-patch overrides it and\nforces generating patch+stat output, so you do not see what it\nis doing.\n\nAlso I do not think we would want to have --sign to format-patch\nanyway; it encourages a wrong workflow. Please see this and\nother messages in the thread:\n\n\thttp://article.gmane.org/gmane.comp.version-control.git/20389\n\nOn a slightly related topic, I sent a message to Pasky about\nthis -s stuff. It means something slightly different in\ndiff-files (instead of asking for no output, it behaves as a\nno-op there), and we can remove that compatibility wart once\nCogito stops using \"diff-files -s\" when it wants to do\n\"diff-files\" in cg-merge (and I suspect that diff-files is\nunnecessary).\n\n> 2) Unhandled ranges list\n>\n> The second one is not so easy.\n\nThis is a real regression; I was hoping Porcelain writers were\npaying attention of what are coming, but obviously the\ndescription in \"What's in git.git\" messages and discussion on\nthe list were not detailed enough. My apologies.\n\nHaving said that, I think what Linus says about equilvalence\nbetween \"a..b\" and \"^a b\" makes whole lot of sense. However, I\ncould argue both ways. Linus's interpretation of \"a..b c..d\" is\n\"^a ^c b d\", but format-patch's interpretation has always been\n\"do '^a b' and then '^c d'\".\n\nThe former is more generic; you could say \"not in A nor B but in\nC pretty easily -- list of ranges cannot express something like\nthat. On the other hand, at least in the context of usual\nformat-patch, the convenience of being able to work on more than\none ranges in sequence may far outweigh the restriction of not\nbeing able to say something like that.\n\nAs an easy alternative, we could give --start-number= to\nformat-patch so that you can do the iteration yourself instead\nof having format-patch to iterate over the list.\n"},{"id":"20702","messageId":"e5bfff550605251310n251df046r5124ec018688d321@mail.gmail.com","threadId":"4293","inReplyTo":"Pine.LNX.4.64.0605251233300.5623@g5.osdl.org","subject":"Re: git-format-patch possible regressions","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-05-25T20:10:01Z","receivedAt":"2006-05-25T20:10:01Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/25/06, Linus Torvalds wrote:\n>\n>\n> The \"x..y\" format is defined to mean the same thing \"y ^x\", and that means\n> that \"HEAD^..HEAD HEAD^^..HEAD^\" really does mean the same thing as\n> \"^HEAD^ ^HEAD^^ HEAD HEAD^\", which in turn means the same thing as \"^HEAD^\n> HEAD\" from a reachability standpoint (since HEAD^ is by definition\n> reachable from HEAD, adding it won't change the revision list, and the\n> same goes for ^HEAD^^ vs ^HEAD^).\n>\n> So thus \"HEAD^..HEAD HEAD^^..HEAD^\" really _is_ the same thing as\n> \"HEAD^..HEAD\", and any tool that thought otherwise was just being\n> very confused.\n>\n\nPerhaps I have chose the wrong example but it was _only_\ninstrumental in better explaing the regression.\n\nThe general problem is how to format patches files named with\nconsecutive numbers starting from a set of possible unrelated\nrevisions.\n\n> Now, we could choose to try to make \"a..b\" mean something else (ie make\n> the \"^a\" part only meaningful for that particular \"sub-query\"), and yes,\n> in many ways that would be a more intuitive thing, but it's not how git\n> revision descriptions work currently, and if we make that change we should\n> do it across the board.\n>\n> (It's not an easy change to make, but it should be possible by having\n> multiple separate NECESSARY/UNNECESSARY bits, and make the revision\n> walking logic a whole lot more complicated than it already is).\n>\n> So I'd argue that you should really do something like\n>\n> ( git-rev-list a..b ; git-rev-list c..d ) |\n> git-format-patch --stdin\n>\n> in qgit if you want the ranges to be truly independent.\n>\n> (And no, I don't think git-format-patch takes a \"--stdin\" argument, but it\n> might not be unreasonable to add it as a generic revision walking\n> argument for scripting like this).\n>\n\nTo fix qgit problem could be enough to add/modify the option -nx to\nmake git-format-patch do not default with 0001 number but with x and\nthen simply call git-format-patch in a loop:\n\n for(int i = 0; i selectedRevisions[i] ^selectedRevisions[i];\n\n\nBut of course it is clear your suggestion could be a solution for\nmuch broader cases.\n\n Marco\n"},{"id":"20703","messageId":"e5bfff550605251321t7378b427p68ffe2e16a54b3ff@mail.gmail.com","threadId":"4293","inReplyTo":"7vhd3dubd9.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-format-patch possible regressions","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-05-25T20:21:31Z","receivedAt":"2006-05-25T20:21:31Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"> > Both regressions brake qgit. The first one is easy to fix (--signoff --> -s)\n>\n> I do not think -s does what you want. It means \"do not generate\n> diff\" to the diff family, but format-patch overrides it and\n> forces generating patch+stat output, so you do not see what it\n> is doing.\n>\n\nSorry, I was fooled by git-format-patch.txt documentation.\n\n\n> > 2) Unhandled ranges list\n> >\n> > The second one is not so easy.\n>\n> This is a real regression; I was hoping Porcelain writers were\n> paying attention of what are coming, but obviously the\n> description in \"What's in git.git\" messages and discussion on\n> the list were not detailed enough. My apologies.\n>\n\nSorry also for this, normally I read \"What's in git.git\" but perhaps I\nmissed this.\n\n\n>\n> As an easy alternative, we could give --start-number= to\n> format-patch so that you can do the iteration yourself instead\n> of having format-patch to iterate over the list.\n>\n>\n\nYou beat me for few minutes ;-)\n\n Marco\n"},{"id":"20711","messageId":"Pine.LNX.4.63.0605252338530.31700@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4293","inReplyTo":"7vhd3dubd9.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-format-patch possible regressions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-25T21:55:11Z","receivedAt":"2006-05-25T21:55:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 May 2006, Junio C Hamano wrote:\n\n> \"Marco Costalba\" writes:\n> \n> > 2) Unhandled ranges list\n> >\n> > The second one is not so easy.\n> \n> This is a real regression;\n\nI was not aware of the possibility to specify several ranges, mostly \nbecause I did not use it that way.\n\nHowever, I think it is worth breaking this in that particular case, since \nthe range handling has become unified with the framework in revision.[ch]\n\n> As an easy alternative, we could give --start-number= to\n> format-patch so that you can do the iteration yourself instead\n> of having format-patch to iterate over the list.\n\nSomething like this?\n\n---\n[PATCH] format-patch: support --start-number= (and --start-number )\n\nThis option implicitely sets numbered mode and starts the numbering with .\n\nSigned-off-by: Johannes Schindelin \n---\n builtin-log.c | 19 ++++++++++++++++---\n 1 files changed, 16 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-log.c b/builtin-log.c\nindex c8feb0f..4e3388b 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -148,6 +148,7 @@ int cmd_format_patch(int argc, const cha\n \tint nr = 0, total, i, j;\n \tint use_stdout = 0;\n \tint numbered = 0;\n+\tint start_number = -1;\n \tint keep_subject = 0;\n \n \tinit_revisions(&rev);\n@@ -171,7 +172,14 @@ int cmd_format_patch(int argc, const cha\n \t\telse if (!strcmp(argv[i], \"-n\") ||\n \t\t\t\t!strcmp(argv[i], \"--numbered\"))\n \t\t\tnumbered = 1;\n-\t\telse if (!strcmp(argv[i], \"-k\") ||\n+\t\telse if (!strncmp(argv[i], \"--start-number=\", 15))\n+\t\t\tstart_number = strtol(argv[i] + 15, NULL, 10);\n+\t\telse if (!strcmp(argv[i], \"--start-number\")) {\n+\t\t\ti++;\n+\t\t\tif (i == argc)\n+\t\t\t\tdie(\"Need a number for --start-number\");\n+\t\t\tstart_number = strtol(argv[i], NULL, 10);\n+\t\t} else if (!strcmp(argv[i], \"-k\") ||\n \t\t\t\t!strcmp(argv[i], \"--keep-subject\")) {\n \t\t\tkeep_subject = 1;\n \t\t\trev.total = -1;\n@@ -193,6 +201,11 @@ int cmd_format_patch(int argc, const cha\n \t}\n \targc = j;\n \n+\tif (start_number >= 0)\n+\t\tnumbered = 1;\n+\telse if (numbered)\n+\t\tstart_number = 1;\n+\n \tif (numbered && keep_subject < 0)\n \t\tdie (\"-n and -k are mutually exclusive.\");\n \n@@ -219,11 +232,11 @@ int cmd_format_patch(int argc, const cha\n \t}\n \ttotal = nr;\n \tif (numbered)\n-\t\trev.total = total;\n+\t\trev.total = total + start_number - 1;\n \twhile (0 <= --nr) {\n \t\tint shown;\n \t\tcommit = list[nr];\n-\t\trev.nr = total - nr;\n+\t\trev.nr = rev.total - nr;\n \t\tif (!use_stdout)\n \t\t\treopen_stdout(commit, rev.nr, keep_subject);\n \t\tshown = log_tree_commit(&rev, commit);\n-- \n1.3.3.gd515\n"},{"id":"20712","messageId":"Pine.LNX.4.63.0605260014340.13003@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4293","inReplyTo":"Pine.LNX.4.63.0605252338530.31700@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git-format-patch possible regressions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-25T22:18:12Z","receivedAt":"2006-05-25T22:18:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 May 2006, Johannes Schindelin wrote:\n\n> @@ -193,6 +201,11 @@ int cmd_format_patch(int argc, const cha\n> \t}\n> \targc = j;\n> \n> +\tif (start_number >= 0)\n> +\t\tnumbered = 1;\n> +\telse if (numbered)\n> +\t\tstart_number = 1;\n> +\n> \tif (numbered && keep_subject < 0)\n> \t\tdie (\"-n and -k are mutually exclusive.\");\n> \n\nThinking about this again, it makes more sense not to imply --numbered:\n\n\tif (numbered && start_number < 0)\n\t\tstart_number = 1;\n\nCiao,\nDscho\n"},{"id":"20713","messageId":"7vy7wpr97n.fsf@assigned-by-dhcp.cox.net","threadId":"4293","inReplyTo":"Pine.LNX.4.63.0605260014340.13003@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git-format-patch possible regressions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-25T23:11:24Z","receivedAt":"2006-05-25T23:11:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Thinking about this again, it makes more sense not to imply --numbered:\n\nYes, that makes sense. That way you can say \"Please start\nnaming the output files at 0032-xxxx.txt, because you gave me 31\npatch series last time, but I do not want [PATCH x/y] on the\nsubject line, just [PATCH]\".\n\nThat brings up another issue. Don't we need to have another\noption --total-number that overrides the /y part above?\n\nHmm...\n"},{"id":"20714","messageId":"Pine.LNX.4.63.0605260125420.16816@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4293","inReplyTo":"7vy7wpr97n.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-format-patch possible regressions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-25T23:28:54Z","receivedAt":"2006-05-25T23:28:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 May 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Thinking about this again, it makes more sense not to imply --numbered:\n> \n> Yes, that makes sense. That way you can say \"Please start\n> naming the output files at 0032-xxxx.txt, because you gave me 31\n> patch series last time, but I do not want [PATCH x/y] on the\n> subject line, just [PATCH]\".\n> \n> That brings up another issue. Don't we need to have another\n> option --total-number that overrides the /y part above?\n\nI thought about that, too. Isn't the --numbered only useful for submitting \na patch series via mail? And isn't it necessary to make certain that these \npatches really apply in that order? Isn't it then sensible to force the \nuser to have a branch (at least a throw-away one) having exactly these \npatches, just to make sure that the patches really, really apply in that \norder?\n\nIf all that is true, then --start-number && --numbered does not make sense \nat all.\n\nCiao,\nDscho\n"},{"id":"20740","messageId":"e5bfff550605252309h2c4b74bcp50b095e09e6c133f@mail.gmail.com","threadId":"4293","inReplyTo":"Pine.LNX.4.63.0605260125420.16816@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git-format-patch possible regressions","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-05-26T06:09:12Z","receivedAt":"2006-05-26T06:09:12Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/26/06, Johannes Schindelin wrote:\n> Hi,\n>\n> On Thu, 25 May 2006, Junio C Hamano wrote:\n>\n> > Johannes Schindelin writes:\n> >\n> > > Thinking about this again, it makes more sense not to imply --numbered:\n> >\n> > Yes, that makes sense. That way you can say \"Please start\n> > naming the output files at 0032-xxxx.txt, because you gave me 31\n> > patch series last time, but I do not want [PATCH x/y] on the\n> > subject line, just [PATCH]\".\n> >\n> > That brings up another issue. Don't we need to have another\n> > option --total-number that overrides the /y part above?\n>\n> I thought about that, too. Isn't the --numbered only useful for submitting\n> a patch series via mail? And isn't it necessary to make certain that these\n> patches really apply in that order? Isn't it then sensible to force the\n> user to have a branch (at least a throw-away one) having exactly these\n> patches, just to make sure that the patches really, really apply in that\n> order?\n>\n> If all that is true, then --start-number && --numbered does not make sense\n> at all.\n>\n\nI was thinking, probably wrong, that the number prepended in file name\nis used also to disambiguate two patches with the same subject.\n\n\n Marco\n"},{"id":"20741","messageId":"7v4pzdqpit.fsf@assigned-by-dhcp.cox.net","threadId":"4293","inReplyTo":"e5bfff550605252309h2c4b74bcp50b095e09e6c133f@mail.gmail.com","subject":"Re: git-format-patch possible regressions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-26T06:16:42Z","receivedAt":"2006-05-26T06:16:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> I was thinking, probably wrong, that the number prepended in file name\n> is used also to disambiguate two patches with the same subject.\n\nWhat Johannes and I were discussing was the other number -- the\ntotal in the series. IOW, y in \"[PATCH x/y]\". OTOH, the number\nused for disambiguation you care about is x, which is made\nadjustable with --start-number patch.\n\nSo the way for qgit to use it would become something like this.\nInstead of giving a list of ranges like \"a..b c..d e..f\":\n\n * Run \"format-patch a..b\"; by reading from its stdout you know\n what patches you got -- you count them.\n\n * Run \"format-patch --start-number=6 c..d\" (if you got 5 out of\n a..b);\n\n * Run \"format-patch --start-number=n e..f\" (now you know the drill).\n\nThen the sequence out of c..d would start with a file 0006-xxxx.txt,\nwhich is what you want for disambiguation.\n"},{"id":"20742","messageId":"e56734$nj7$1@sea.gmane.org","threadId":"4293","inReplyTo":"7v4pzdqpit.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-format-patch possible regressions","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-26T06:26:49Z","receivedAt":"2006-05-26T06:26:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> So the way for qgit to use it would become something like this.\n> Instead of giving a list of ranges like \"a..b c..d e..f\":\n> \n> * Run \"format-patch a..b\"; by reading from its stdout you know\n> what patches you got -- you count them.\n> \n> * Run \"format-patch --start-number=6 c..d\" (if you got 5 out of\n> a..b);\n[...]\n\nI still think that having _shortcut notation_ being different for very\ndifferent commands is not a bad idea.\n\nIf one is really concerned about consistency of rev-list options, we could\nuse ',' or something to separate separate lists of commits, e.g.\n\n git format-patch a..b , c..d , e..f\n\nor\n\n git format-patch a..b --then c..d --then e..f\n\nWhat do you think about the idea?\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"20783","messageId":"e5bfff550605270212n267661rd0463a301cbe1b95@mail.gmail.com","threadId":"4293","inReplyTo":"7v4pzdqpit.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-format-patch possible regressions","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-05-27T09:12:56Z","receivedAt":"2006-05-27T09:12:56Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/26/06, Junio C Hamano wrote:\n>\n> What Johannes and I were discussing was the other number -- the\n> total in the series. IOW, y in \"[PATCH x/y]\". OTOH, the number\n> used for disambiguation you care about is x, which is made\n> adjustable with --start-number patch.\n>\n\nNew --start-number patch says:\n\n\"Since the \"a..b c..d\" syntax is interpreted as \"b ^a d ^c\" as other\nrange-ish commands, if you want to format a..b and then c..d and end\nup with files consecutively numbered, the second run needs to be able\nto tell the command what number to start from.\n\nThis does not imply --numbered (which gives [PATCH n/m] to the subject).\"\n\nActually it seems that --numbered is needed anyway.\n\n$ git-format-patch HEAD^..HEAD\n0000-git-format-patch-start-number-n.txt\n$ git-format-patch --start-number=7 HEAD^..HEAD\n0000-git-format-patch-start-number-n.txt\n$ git-format-patch --numbered --start-number=7 HEAD^..HEAD\n0007-git-format-patch-start-number-n.txt\n\nBut with numbered also the patch subject is changed with added [PATCH n/m] that\nis not needed.\n\nAlso mutually exclusive check is not performed\ngit-format-patch -n -k HEAD^..HEAD\n0001-git-format-patch-start-number-n.txt\n\nThis patch should fix all.\n\nSubject: [PATCH] Let git-format-patch --start-number option to work\nalso without --numbered\n\nWhile there also fix the check for mutually exclusive -n and -k option\n\nSigned-off-by: Marco Costalba \n---\n builtin-log.c | 8 ++++----\n 1 files changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-log.c b/builtin-log.c\nindex 71f4ff9..c35733f 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -148,7 +148,7 @@ int cmd_format_patch(int argc, const cha\n \tint nr = 0, total, i, j;\n \tint use_stdout = 0;\n \tint numbered = 0;\n-\tint start_number = -1;\n+\tint start_number = 0;\n \tint keep_subject = 0;\n\n \tinit_revisions(&rev);\n@@ -201,9 +201,9 @@ int cmd_format_patch(int argc, const cha\n \t}\n \targc = j;\n\n-\tif (numbered && start_number < 0)\n+\tif (numbered && start_number == 0)\n \t\tstart_number = 1;\n-\tif (numbered && keep_subject < 0)\n+\tif (numbered && keep_subject)\n \t\tdie (\"-n and -k are mutually exclusive.\");\n\n \targc = setup_revisions(argc, argv, &rev, \"HEAD\");\n@@ -233,7 +233,7 @@ int cmd_format_patch(int argc, const cha\n \twhile (0 <= --nr) {\n \t\tint shown;\n \t\tcommit = list[nr];\n-\t\trev.nr = rev.total - nr;\n+\t\trev.nr = start_number + total - nr - 1;\n \t\tif (!use_stdout)\n \t\t\treopen_stdout(commit, rev.nr, keep_subject);\n \t\tshown = log_tree_commit(&rev, commit);\n-- \n1.3.3.gfa0f-dirty\n"},{"id":"20818","messageId":"Pine.LNX.4.63.0605281154300.1862@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4293","inReplyTo":"e5bfff550605270212n267661rd0463a301cbe1b95@mail.gmail.com","subject":"Re: git-format-patch possible regressions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-28T09:57:18Z","receivedAt":"2006-05-28T09:57:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 27 May 2006, Marco Costalba wrote:\n\n> [...patch that fixes late-night-hackery...]\n\nAcked-By: Johannes Schindelin \n\nCiao,\nDscho\n"}]}