{"thread":{"id":"56665","subject":"git format-patch --range-diff accepts non-quoted arguments (shouldn't it be?)","startedAt":"2021-10-08T09:34:36Z","lastAt":"2021-10-08T18:11:05Z","messageCount":2,"participants":["Bagas Sanjaya","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"438288","messageId":"c2c5f3b0-dfdb-0f3f-4c64-8f44d3e74a07@gmail.com","threadId":"56665","inReplyTo":null,"subject":"git format-patch --range-diff accepts non-quoted arguments (shouldn't it be?)","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-10-08T09:34:15Z","receivedAt":"2021-10-08T09:34:36Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"\nHi,\n\nI think it is rather odd that `git format-patch --range-diff` accepts \n<previous> argument without enclosed in quotes, since it is always \nmulti-word (separated by space). E.g., below works:\n\n     $ git format-patch <options> --range-diff=main..previous main..HEAD\n\nbut below returns nothing:\n\n     $ git format-patch <options> --range-diff=\"main..previous main..HEAD\"\n\nShould the quoted <previous> argument to --range-diff be allowed, and \nforbid the unquoted counterpart?\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"438305","messageId":"xmqq7denl750.fsf@gitster.g","threadId":"56665","inReplyTo":"c2c5f3b0-dfdb-0f3f-4c64-8f44d3e74a07@gmail.com","subject":"Re: git format-patch --range-diff accepts non-quoted arguments (shouldn't it be?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-08T18:10:35Z","receivedAt":"2021-10-08T18:11:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bagas Sanjaya <bagasdotme@gmail.com> writes:\n\n> I think it is rather odd that `git format-patch --range-diff` accepts\n> <previous> argument without enclosed in quotes, since it is always \n> multi-word (separated by space). E.g., below works:\n\nWhat do you mean by \"it\" in \"since it is always\"?  If you meant\n\"<previous>\", your may want to re-read \"git format-patch --help\".\n\nThe <previous> will most likely not be a multi-word argument\nseparated by a space.  It is a way to specify the \"previous range\",\ni.e. one of the two ranges given to the range-diff command to be\ncompared.  The other range is what the user gave the command to\nspecify what patches to work on for the latest iteration.\n\nSo...\n\n>     $ git format-patch <options> --range-diff=main..previous main..HEAD\n\nThis works of course, because <previous> is main..previous (without\nany SP anywhere, and needs no quoting), main..HEAD is the range to\ntake patches from *and* also given to range-diff as the current\nrange.\n\n> but below returns nothing:\n>\n>     $ git format-patch <options> --range-diff=\"main..previous main..HEAD\"\n\nThis gives an empty range to work on to the command.  The range-diff\nargument seems strange, but if we are not emitting a single patch or\ncover letter, perhaps there is no place to emit the range-diff so it\nmay not get any complaint.\n\n> Should the quoted <previous> argument to --range-diff be allowed, and\n> forbid the unquoted counterpart?\n\nNo, I think the command is fine as-is.\n\nStepping back a bit, if you have two topics (perhaps related,\nperhaps not) forked from the mainline, but you want to present\nthem as a single unit to the outside world, you may do this:\n\n    $ git format-patch ^master topic-1 topic-2\n\nIf two topics share their early commits and their later commits are\nindependent and do not interact with each other, this command line\nshould do the right thing to emit shared ones only once.\n\nIf these were the second iteration, I would imagine\n\n    $ git format-patch \\\n\t--range-diff='^master@{last.week} topic-1@{last.week} topic-2@{last.week}' \\\n\t^master topic-1 topic-2\n\nwould be a good way to include the range-diff for this round\nrelative to the previous round you sent last week.\n\nSo, quoting <previous> may be necessary in a more complex usecase,\nbut most of the time you should not have to quote.\n\nHTH.\n"}]}