{"thread":{"id":"29705","subject":"git log -z doesn't separate commits with NULs","startedAt":"2012-02-23T09:14:23Z","lastAt":"2012-03-03T13:41:02Z","messageCount":22,"participants":["Nikolaj Shurkaev","Luke Diamand","Johannes Sixt","Jeff King","Andreas Schwab","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"185247","messageId":"4F46036F.3040406@gmail.com","threadId":"29705","inReplyTo":null,"subject":"git log -z doesn't separate commits with NULs","fromName":"Nikolaj Shurkaev","fromEmail":"snnicky@gmail.com","sentAt":"2012-02-23T09:14:23Z","receivedAt":"2012-02-23T09:14:23Z","isPatch":false,"sender":{"key":"snnicky@gmail.com","avatar":null},"body":"Hello all.\n\nI wanted to generate several files with some statistics using \"git log \n-z\" command.\nI did something like this:\ngit log -z --patch HEAD~10..HEAD -- SomePathHere | xargs -0 \n--max-chars=1000000 ~/1.sh\n\nIf I put\necho \"started\"\ninto the file  ~/1.sh I see that the file is called only once instead of \nmultiple times.\n\nI'm newbie to xargs, thus I tested with and that worked as I expected.\nfind . -type f -print0 | xargs -0  ./1.sh\nThat produced a lost of \"started\" lines.\n\nThus I suspect there is a but in git log -z command and that doesn't \n\"Separate the commits with NULs instead of with new newlines.\" as \npromised in the documents.\nIs my understanding correct or I don't understand the documentation or \nsomehow pass wrong parameters into git log?\n\nThank you.\nBest regards,\nNikolaj\n"},{"id":"185255","messageId":"4F460EB7.3030503@diamand.org","threadId":"29705","inReplyTo":"4F46036F.3040406@gmail.com","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2012-02-23T10:02:31Z","receivedAt":"2012-02-23T10:02:31Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"On 23/02/12 09:14, Nikolaj Shurkaev wrote:\n> Hello all.\n>\n> I wanted to generate several files with some statistics using \"git log\n> -z\" command.\n> I did something like this:\n> git log -z --patch HEAD~10..HEAD -- SomePathHere | xargs -0\n> --max-chars=1000000 ~/1.sh\n>\n> If I put\n> echo \"started\"\n> into the file ~/1.sh I see that the file is called only once instead of\n> multiple times.\n>\n> I'm newbie to xargs, thus I tested with and that worked as I expected.\n> find . -type f -print0 | xargs -0 ./1.sh\n> That produced a lost of \"started\" lines.\n>\n> Thus I suspect there is a but in git log -z command and that doesn't\n> \"Separate the commits with NULs instead of with new newlines.\" as\n> promised in the documents.\n> Is my understanding correct or I don't understand the documentation or\n> somehow pass wrong parameters into git log?\n\nJust a guess, but doesn't the \"--patch\" option to git log ask it to \nproduce a patch output? Surely that will override the -z: patch will not \nbe expecting NULs.\n\n>\n> Thank you.\n> Best regards,\n> Nikolaj\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"185258","messageId":"4F46122F.2040409@kdbg.org","threadId":"29705","inReplyTo":"4F46036F.3040406@gmail.com","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2012-02-23T10:17:19Z","receivedAt":"2012-02-23T10:17:19Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 23.02.2012 10:14, schrieb Nikolaj Shurkaev:\n> I wanted to generate several files with some statistics using \"git log\n> -z\" command.\n> I did something like this:\n> git log -z --patch HEAD~10..HEAD -- SomePathHere | xargs -0\n> --max-chars=1000000 ~/1.sh\n> \n> If I put\n> echo \"started\"\n> into the file  ~/1.sh I see that the file is called only once instead of\n> multiple times.\n\nThat is because xargs calls the program with as many arguments as\npossible, unless directed otherwise. Put this in the script:\n\n\techo \"started $*\"\n\nand repeat. Then try this:\n\n ... | xargs -0 -n 1 ~/1.sh\n\n-- Hannes\n"},{"id":"185259","messageId":"20120223102426.GB2912@sigill.intra.peff.net","threadId":"29705","inReplyTo":"4F46036F.3040406@gmail.com","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-23T10:24:26Z","receivedAt":"2012-02-23T10:24:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 23, 2012 at 12:14:23PM +0300, Nikolaj Shurkaev wrote:\n\n> I wanted to generate several files with some statistics using \"git\n> log -z\" command.\n> I did something like this:\n> git log -z --patch HEAD~10..HEAD -- SomePathHere | xargs -0\n> --max-chars=1000000 ~/1.sh\n\nI'm not sure what \"1.sh\" is expecting to take as input, but that will\nfeed entire commits, including their commit message and entire diff, to\nthe script on its command line.\n\nThat seems like an awkward interface, but we don't really know what your\nscript intends to do. Maybe it is worth sharing the contents of the\nscript.\n\n> If I put echo \"started\" into the file  ~/1.sh I see that the file is\n> called only once instead of multiple times.\n\nYes. The point of xargs is usually to cram as many arguments into each\ninvocation of \"1.sh\" as possible, splitting into multiple invocations\nonly when we hit the argument-list memory limit that the OS imposes.\n\nIf you want xargs to give each argument its own invocation of the\nscript, use \"xargs -n1\".\n\n> I'm newbie to xargs, thus I tested with and that worked as I expected.\n> find . -type f -print0 | xargs -0  ./1.sh\n> That produced a lost of \"started\" lines.\n\nIf you instrument your 1.sh more[1], you will find that is not executing\nonce per file, but rather getting a large chunk of files per invocation.\n\n[1] Try adding: echo \"got args: $*\"\n\n> Thus I suspect there is a but in git log -z command and that doesn't\n> \"Separate the commits with NULs instead of with new newlines.\" as\n> promised in the documents.\n\nYou could verify that assertion by looking at the output. Try piping\nyour \"git log\" command through \"cat -A | less\". When I try it, I see a\nNUL between each commit (cat -A will show it as \"^@\").\n\n-Peff\n"},{"id":"185260","messageId":"20120223102702.GC2912@sigill.intra.peff.net","threadId":"29705","inReplyTo":"4F460EB7.3030503@diamand.org","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-23T10:27:03Z","receivedAt":"2012-02-23T10:27:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 23, 2012 at 10:02:31AM +0000, Luke Diamand wrote:\n\n> >Thus I suspect there is a but in git log -z command and that doesn't\n> >\"Separate the commits with NULs instead of with new newlines.\" as\n> >promised in the documents.\n> >Is my understanding correct or I don't understand the documentation or\n> >somehow pass wrong parameters into git log?\n> \n> Just a guess, but doesn't the \"--patch\" option to git log ask it to\n> produce a patch output? Surely that will override the -z: patch will\n> not be expecting NULs.\n\nNo. You will get the patch text and the log message together, with\ncommits separated by NUL. Some diff output formats will also respect\n\"-z\" to produce NULs internally (e.g., \"--raw\" will use it to separate\nfilenames), but \"--patch\" does not.\n\n-Peff\n"},{"id":"185261","messageId":"m262exrg65.fsf@igel.home","threadId":"29705","inReplyTo":"4F46036F.3040406@gmail.com","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-02-23T10:35:14Z","receivedAt":"2012-02-23T10:35:14Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Nikolaj Shurkaev <snnicky@gmail.com> writes:\n\n> I did something like this:\n> git log -z --patch HEAD~10..HEAD -- SomePathHere | xargs -0 \n> --max-chars=1000000 ~/1.sh\n>\n> If I put\n> echo \"started\"\n> into the file  ~/1.sh I see that the file is called only once instead of\n> multiple times.\n\nIf you want the command to be called once for each commit you need to\npass --max-args=1 to xargs.  Otherwise xargs will cumulate the arguments\nuntil --max-chars is reached, and the command is expected to loop over\nthem.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"185266","messageId":"4F462CF2.5040502@gmail.com","threadId":"29705","inReplyTo":"4F46122F.2040409@kdbg.org","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Nikolaj Shurkaev","fromEmail":"snnicky@gmail.com","sentAt":"2012-02-23T12:11:30Z","receivedAt":"2012-02-23T12:11:30Z","isPatch":false,"sender":{"key":"snnicky@gmail.com","avatar":null},"body":"Hello.\n\nYou were right. I added parameter --max-args=1 to xargs command and that \nstarted work as I wanted initially.\nThank you very much.\n\n--\nNikolaj\n\n23.02.2012 13:17, Johannes Sixt пишет:\n> Am 23.02.2012 10:14, schrieb Nikolaj Shurkaev:\n>> I wanted to generate several files with some statistics using \"git log\n>> -z\" command.\n>> I did something like this:\n>> git log -z --patch HEAD~10..HEAD -- SomePathHere | xargs -0\n>> --max-chars=1000000 ~/1.sh\n>>\n>> If I put\n>> echo \"started\"\n>> into the file  ~/1.sh I see that the file is called only once instead of\n>> multiple times.\n> That is because xargs calls the program with as many arguments as\n> possible, unless directed otherwise. Put this in the script:\n>\n> \techo \"started $*\"\n>\n> and repeat. Then try this:\n>\n>   ... | xargs -0 -n 1 ~/1.sh\n>\n> -- Hannes\n>\n"},{"id":"185267","messageId":"4F462E61.4020203@gmail.com","threadId":"29705","inReplyTo":"20120223102426.GB2912@sigill.intra.peff.net","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Nikolaj Shurkaev","fromEmail":"snnicky@gmail.com","sentAt":"2012-02-23T12:17:37Z","receivedAt":"2012-02-23T12:17:37Z","isPatch":false,"sender":{"key":"snnicky@gmail.com","avatar":null},"body":"Hello.\n\nThank you very much for your tips. They really helped me. I was trying \nto create patches that would affect only some given files or folders. By \nthis moment I have the following:\n\nGeneratePatches.sh\n---------------------\n#!/bin/bash\n#parameter 1 - <since>..<to>\n#parameter 2 - path to file\ngit log -z --reverse --format=email --patch \"$1\" -- \"$2\" | xargs --null \n--max-args=1 ./CreatePatchFile.sh\n---------------------\n\nand CreatePatchFile.sh\n---------------------\n#!/bin/bash\n\nmyPatchNumber=$(ls ./*-patch.patch 2>/dev/null | wc -l)\nlet \"myPatchNumber += 1\"\n\npatchFile=\"./\"$(printf \"%04d\" $myPatchNumber)\"-patch.patch\"\necho \"$@\" > \"$patchFile\"\n---------------------\n\nI call\n./GeneratePatches.sh HEAD~3..HEAD SomePath\nand that produces something very similar to what I want.\n\nPerhaps there is a better way to do that.\n\nThank you once again.\n---\nBest regards,\nNikolaj\n\n23.02.2012 13:24, Jeff King пишет:\n> On Thu, Feb 23, 2012 at 12:14:23PM +0300, Nikolaj Shurkaev wrote:\n>\n>> I wanted to generate several files with some statistics using \"git\n>> log -z\" command.\n>> I did something like this:\n>> git log -z --patch HEAD~10..HEAD -- SomePathHere | xargs -0\n>> --max-chars=1000000 ~/1.sh\n> I'm not sure what \"1.sh\" is expecting to take as input, but that will\n> feed entire commits, including their commit message and entire diff, to\n> the script on its command line.\n>\n> That seems like an awkward interface, but we don't really know what your\n> script intends to do. Maybe it is worth sharing the contents of the\n> script.\n>\n>> If I put echo \"started\" into the file  ~/1.sh I see that the file is\n>> called only once instead of multiple times.\n> Yes. The point of xargs is usually to cram as many arguments into each\n> invocation of \"1.sh\" as possible, splitting into multiple invocations\n> only when we hit the argument-list memory limit that the OS imposes.\n>\n> If you want xargs to give each argument its own invocation of the\n> script, use \"xargs -n1\".\n>\n>> I'm newbie to xargs, thus I tested with and that worked as I expected.\n>> find . -type f -print0 | xargs -0  ./1.sh\n>> That produced a lost of \"started\" lines.\n> If you instrument your 1.sh more[1], you will find that is not executing\n> once per file, but rather getting a large chunk of files per invocation.\n>\n> [1] Try adding: echo \"got args: $*\"\n>\n>> Thus I suspect there is a but in git log -z command and that doesn't\n>> \"Separate the commits with NULs instead of with new newlines.\" as\n>> promised in the documents.\n> You could verify that assertion by looking at the output. Try piping\n> your \"git log\" command through \"cat -A | less\". When I try it, I see a\n> NUL between each commit (cat -A will show it as \"^@\").\n>\n> -Peff\n>\n"},{"id":"185268","messageId":"4F462EC5.6090007@gmail.com","threadId":"29705","inReplyTo":"m262exrg65.fsf@igel.home","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Nikolaj Shurkaev","fromEmail":"snnicky@gmail.com","sentAt":"2012-02-23T12:19:17Z","receivedAt":"2012-02-23T12:19:17Z","isPatch":false,"sender":{"key":"snnicky@gmail.com","avatar":null},"body":"Thank you.\n\nThat really helped me.\n---\nNikolaj\n\n23.02.2012 13:35, Andreas Schwab пишет:\n> Nikolaj Shurkaev<snnicky@gmail.com>  writes:\n>\n>> I did something like this:\n>> git log -z --patch HEAD~10..HEAD -- SomePathHere | xargs -0\n>> --max-chars=1000000 ~/1.sh\n>>\n>> If I put\n>> echo \"started\"\n>> into the file  ~/1.sh I see that the file is called only once instead of\n>> multiple times.\n> If you want the command to be called once for each commit you need to\n> pass --max-args=1 to xargs.  Otherwise xargs will cumulate the arguments\n> until --max-chars is reached, and the command is expected to loop over\n> them.\n>\n> Andreas.\n>\n"},{"id":"185273","messageId":"m34nuhelnf.fsf@localhost.localdomain","threadId":"29705","inReplyTo":"4F462E61.4020203@gmail.com","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-02-23T13:15:21Z","receivedAt":"2012-02-23T13:15:21Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nikolaj Shurkaev <snnicky@gmail.com> writes:\n\n> Thank you very much for your tips. They really helped me. I was trying\n> to create patches that would affect only some given files or\n> folders. By this moment I have the following:\n> \n> GeneratePatches.sh\n> ---------------------\n> #!/bin/bash\n> #parameter 1 - <since>..<to>\n> #parameter 2 - path to file\n> git log -z --reverse --format=email --patch \"$1\" -- \"$2\" | xargs\n> --null --max-args=1 ./CreatePatchFile.sh\n> ---------------------\n> \n> and CreatePatchFile.sh\n> ---------------------\n> #!/bin/bash\n> \n> myPatchNumber=$(ls ./*-patch.patch 2>/dev/null | wc -l)\n> let \"myPatchNumber += 1\"\n> \n> patchFile=\"./\"$(printf \"%04d\" $myPatchNumber)\"-patch.patch\"\n> echo \"$@\" > \"$patchFile\"\n> ---------------------\n> \n> I call\n> ./GeneratePatches.sh HEAD~3..HEAD SomePath\n> and that produces something very similar to what I want.\n> \n> Perhaps there is a better way to do that.\n\nSo what git-format-patch is lacking?\n\n-- \nJakub Narebski\n"},{"id":"185275","messageId":"4F4643BB.8090001@gmail.com","threadId":"29705","inReplyTo":"m34nuhelnf.fsf@localhost.localdomain","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Nikolaj Shurkaev","fromEmail":"snnicky@gmail.com","sentAt":"2012-02-23T13:48:43Z","receivedAt":"2012-02-23T13:48:43Z","isPatch":false,"sender":{"key":"snnicky@gmail.com","avatar":null},"body":"For example there are commits that affect not only files in folder A but \nfiles in folder B, C and so on.\nIf I do format-patch that will give me nice patches, but there are \nmodifications of folders B, C and so on there.\nI do not know a way to generate patches via format-patch that affect \nonly files in folder A.\n\nThis is why I wrote those scripts.\n\n23.02.2012 16:15, Jakub Narebski пишет:\n> Nikolaj Shurkaev<snnicky@gmail.com>  writes:\n>\n>> Thank you very much for your tips. They really helped me. I was trying\n>> to create patches that would affect only some given files or\n>> folders. By this moment I have the following:\n>>\n>> GeneratePatches.sh\n>> ---------------------\n>> #!/bin/bash\n>> #parameter 1 -<since>..<to>\n>> #parameter 2 - path to file\n>> git log -z --reverse --format=email --patch \"$1\" -- \"$2\" | xargs\n>> --null --max-args=1 ./CreatePatchFile.sh\n>> ---------------------\n>>\n>> and CreatePatchFile.sh\n>> ---------------------\n>> #!/bin/bash\n>>\n>> myPatchNumber=$(ls ./*-patch.patch 2>/dev/null | wc -l)\n>> let \"myPatchNumber += 1\"\n>>\n>> patchFile=\"./\"$(printf \"%04d\" $myPatchNumber)\"-patch.patch\"\n>> echo \"$@\">  \"$patchFile\"\n>> ---------------------\n>>\n>> I call\n>> ./GeneratePatches.sh HEAD~3..HEAD SomePath\n>> and that produces something very similar to what I want.\n>>\n>> Perhaps there is a better way to do that.\n> So what git-format-patch is lacking?\n>\n"},{"id":"185292","messageId":"20120223193451.GB30132@sigill.intra.peff.net","threadId":"29705","inReplyTo":"4F4643BB.8090001@gmail.com","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-23T19:34:51Z","receivedAt":"2012-02-23T19:34:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 23, 2012 at 04:48:43PM +0300, Nikolaj Shurkaev wrote:\n\n> For example there are commits that affect not only files in folder A\n> but files in folder B, C and so on.  If I do format-patch that will\n> give me nice patches, but there are modifications of folders B, C and\n> so on there.  I do not know a way to generate patches via format-patch\n> that affect only files in folder A.\n\nDoesn't:\n\n  git format-patch HEAD~3..HEAD SomePath\n\ndo what you want? It is certainly designed to, and it seems to work for\nme.\n\n-Peff\n"},{"id":"185295","messageId":"7vy5rt2u0c.fsf@alter.siamese.dyndns.org","threadId":"29705","inReplyTo":"20120223193451.GB30132@sigill.intra.peff.net","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-23T20:07:47Z","receivedAt":"2012-02-23T20:07:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Thu, Feb 23, 2012 at 04:48:43PM +0300, Nikolaj Shurkaev wrote:\n>\n> Doesn't:\n>\n>   git format-patch HEAD~3..HEAD SomePath\n>\n> do what you want? It is certainly designed to, and it seems to work for\n> me.\n\nIt is not quite \"designed to\", though.\n\nIt happens to work that way, and I do not think we want to forbid its use,\nbut we would want to discourage anybody from blindly using it without\nthinking if the end results suits his/her purpose (and the reason should\nbe obvious to those who think, the hint is \"log message\").\n"},{"id":"185318","messageId":"4F475689.4040203@gmail.com","threadId":"29705","inReplyTo":"7vy5rt2u0c.fsf@alter.siamese.dyndns.org","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Nikolaj Shurkaev","fromEmail":"snnicky@gmail.com","sentAt":"2012-02-24T09:21:13Z","receivedAt":"2012-02-24T09:21:13Z","isPatch":false,"sender":{"key":"snnicky@gmail.com","avatar":null},"body":"Hello.\n\nThank you for the hint.\n\ngit format-patch HEAD~3..HEAD -- SomePath\n\ndoes exactly what I need. But that way of usage is not described in git \ndocumentation thus I thought there is no way to do that. I've just \ndouble checked\n\ngit format-patch --help\n\ndoesn't describe that. I'll propose to put something like this into git \ndocumentation\n--------------------------------------------------------------------------------------------\ndiff --git a/Documentation/git-format-patch.txt \nb/Documentation/git-format-patch.txt\nindex 6ea9be7..63267c6 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -23,6 +23,7 @@ SYNOPSIS\n[--cover-letter] [--quiet]\n[<common diff options>]\n[ <since> | <revision range> ]\n+ [[\\--] <path>...]\n\nDESCRIPTION\n-----------\n@@ -219,6 +220,12 @@ you can use `--suffix=-patch` to get \n`0001-description-of-my-change-patch`.\nrange are always formatted as creation patches, independently\nof this flag.\n\n+[\\--] <path>...::\n+ Put in patches only those modifications that affect specified files\n+ and folders. It's important to understand that log message of the\n+ commit may become inappropriate because some parts of patch may be\n+ cut off.\n+\nCONFIGURATION\n-------------\nYou can specify extra mail header lines to be added to each message,\n--------------------------------------------------------------------------------------------\n\n--\nNikolaj.\n\n23.02.2012 23:07, Junio C Hamano пишет:\n> Jeff King<peff@peff.net>  writes:\n>\n>> On Thu, Feb 23, 2012 at 04:48:43PM +0300, Nikolaj Shurkaev wrote:\n>>\n>> Doesn't:\n>>\n>>    git format-patch HEAD~3..HEAD SomePath\n>>\n>> do what you want? It is certainly designed to, and it seems to work for\n>> me.\n> It is not quite \"designed to\", though.\n>\n> It happens to work that way, and I do not think we want to forbid its use,\n> but we would want to discourage anybody from blindly using it without\n> thinking if the end results suits his/her purpose (and the reason should\n> be obvious to those who think, the hint is \"log message\").\n>\n"},{"id":"185322","messageId":"20120224095253.GC11846@sigill.intra.peff.net","threadId":"29705","inReplyTo":"4F475689.4040203@gmail.com","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-24T09:52:53Z","receivedAt":"2012-02-24T09:52:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 24, 2012 at 12:21:13PM +0300, Nikolaj Shurkaev wrote:\n\n> I'll propose to put something like this into git documentation\n> --------------------------------------------------------------------------------------------\n> diff --git a/Documentation/git-format-patch.txt\n> b/Documentation/git-format-patch.txt\n> index 6ea9be7..63267c6 100644\n> --- a/Documentation/git-format-patch.txt\n> +++ b/Documentation/git-format-patch.txt\n> @@ -23,6 +23,7 @@ SYNOPSIS\n> [--cover-letter] [--quiet]\n> [<common diff options>]\n> [ <since> | <revision range> ]\n> + [[\\--] <path>...]\n> \n> DESCRIPTION\n> -----------\n> @@ -219,6 +220,12 @@ you can use `--suffix=-patch` to get\n> `0001-description-of-my-change-patch`.\n> range are always formatted as creation patches, independently\n> of this flag.\n> \n> +[\\--] <path>...::\n> + Put in patches only those modifications that affect specified files\n> + and folders. It's important to understand that log message of the\n> + commit may become inappropriate because some parts of patch may be\n> + cut off.\n> +\n\nI think that text looks OK. But to my mind, it is not that format-patch\naccepts a path parameter, but rather that it takes arbitrary log-like\narguments. So you could do \"git format-patch --grep=whatever\", or even\nsomething like \"git format-patch --cherry\".\n\nI don't know how well tested every option is, though, so maybe it's not\na good idea to encourage the use of random options.\n\n-Peff\n"},{"id":"185357","messageId":"7vsji0xalg.fsf@alter.siamese.dyndns.org","threadId":"29705","inReplyTo":"20120224095253.GC11846@sigill.intra.peff.net","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-24T20:03:39Z","receivedAt":"2012-02-24T20:03:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> DESCRIPTION\n>> -----------\n>> @@ -219,6 +220,12 @@ you can use `--suffix=-patch` to get\n>> `0001-description-of-my-change-patch`.\n>> range are always formatted as creation patches, independently\n>> of this flag.\n>> \n>> +[\\--] <path>...::\n>> + Put in patches only those modifications that affect specified files\n>> + and folders. It's important to understand that log message of the\n>> + commit may become inappropriate because some parts of patch may be\n>> + cut off.\n>> +\n>\n> I think that text looks OK. But to my mind, it is not that format-patch\n> accepts a path parameter, but rather that it takes arbitrary log-like\n> arguments.\n\nThe above text is not telling the entire truth, though.\n\nWhen the command is run with the \"--full-diff\" option, seleted commits\nwill be shown in full.  This is useful for example when you want to pick\ncommits that add a new \"frotz\" driver, which obviously needs to include\n\"drivers/frotz/\" subdirectory, without missing necessary changes to the\nMakefiles in the higher level (e.g. \"drivers/Makefile\"), e.g.\n\n\tgit format-patch --full-diff v1.0..v1.1 -- drivers/frotz\n\nIn such a case, \"some parts may be cut off\" does not make the log message\ninappropriate.\n\nOn the other hand, people often do not use the resulting history of taking\npartial patches (i.e. without --full-diff) and feeding them to \"am\" as-is.\nThe operation is used merely to give them a starting point for working on\n(possibly) an unrelated topic, and the history is further tweaked with\n\"rebase -i\" or even \"commit --amend\".  It is not \"inappropriate\" that the\nlog says more than what the patch does in such a use case.  What the log\nsays is irrelevant.\n\n> I don't know how well tested every option is, though, so maybe it's not\n> a good idea to encourage the use of random options.\n\nI obviously agree and also suspect that the real question is not \"how well\ntested\" but \"if it makes sense\".\n\nI am reasonably sure that over time the options and features that make\nsense in the context of producing something that is useful with \"am\" have\nbeen already made to work well, but I also am fairly certain that the\ncoverage of the code to explicitly reject options that do not make sense\nin that context would be spotty at best.  For example, did we carefully\ndesign and implement how format-patch should behave when \"-z\" is given,\nor does the code happen to do whatever it happens to do?  If the latter,\ndid we consider rejecting \"-z\" when given from the command line and\nimplement such safety?\n"},{"id":"185370","messageId":"20120224204615.GB21447@sigill.intra.peff.net","threadId":"29705","inReplyTo":"7vsji0xalg.fsf@alter.siamese.dyndns.org","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-24T20:46:15Z","receivedAt":"2012-02-24T20:46:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 24, 2012 at 12:03:39PM -0800, Junio C Hamano wrote:\n\n> The above text is not telling the entire truth, though.\n>\n> When the command is run with the \"--full-diff\" option, seleted commits\n> will be shown in full.  This is useful for example when you want to pick\n> commits that add a new \"frotz\" driver, which obviously needs to include\n> \"drivers/frotz/\" subdirectory, without missing necessary changes to the\n> Makefiles in the higher level (e.g. \"drivers/Makefile\"), e.g.\n> \n> \tgit format-patch --full-diff v1.0..v1.1 -- drivers/frotz\n> \n> In such a case, \"some parts may be cut off\" does not make the log message\n> inappropriate.\n\nTrue. That is also a slightly dangerous thing to do, though, because you\nare omitting full patches in the middle that touch the same paths as the\npatches you include. So I might send you a patch against Makefile that\ndoes not apply, and nor do you have the interim sha1.\n\nOf course that is a general problem with any commit-limiting in\nformat-patch (e.g., --grep), and even with sending patches in general (I\nhave to make sure I based my patch off of something reasonable in the\nfirst place). The key is to be clueful about what you are doing. So\nperhaps we are better off to refer the user to git-log(1), say that\ncommit limiting options in general would work, but be careful with\nsending a partial result.\n\n> On the other hand, people often do not use the resulting history of taking\n> partial patches (i.e. without --full-diff) and feeding them to \"am\" as-is.\n> The operation is used merely to give them a starting point for working on\n> (possibly) an unrelated topic, and the history is further tweaked with\n> \"rebase -i\" or even \"commit --amend\".  It is not \"inappropriate\" that the\n> log says more than what the patch does in such a use case.  What the log\n> says is irrelevant.\n\nRight. I think this comes down to the \"clueful\" bit. If you understand\nwhat it is you are asking git to do and deciding that the consequences\nare OK (either because you are not using the log message, or you know\nthat the subset of a series you are sending should apply to what the\nreceiver has).\n\n> > I don't know how well tested every option is, though, so maybe it's not\n> > a good idea to encourage the use of random options.\n> \n> I obviously agree and also suspect that the real question is not \"how well\n> tested\" but \"if it makes sense\".\n> \n> I am reasonably sure that over time the options and features that make\n> sense in the context of producing something that is useful with \"am\" have\n> been already made to work well, but I also am fairly certain that the\n> coverage of the code to explicitly reject options that do not make sense\n> in that context would be spotty at best.  For example, did we carefully\n> design and implement how format-patch should behave when \"-z\" is given,\n> or does the code happen to do whatever it happens to do?  If the latter,\n> did we consider rejecting \"-z\" when given from the command line and\n> implement such safety?\n\nYeah, I think that is a good way of putting it. I tend to think the\ncommit-limiting options are the useful and working ones, which is why I\nsuggested mentioning them explicitly above. But I admit I don't use them\nmyself, so I'm just guessing.\n\n-Peff\n"},{"id":"185378","messageId":"7vk43cx7c2.fsf@alter.siamese.dyndns.org","threadId":"29705","inReplyTo":"20120224204615.GB21447@sigill.intra.peff.net","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-24T21:14:05Z","receivedAt":"2012-02-24T21:14:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> True. That is also a slightly dangerous thing to do, though, because you\n> are omitting full patches in the middle that touch the same paths as the\n> patches you include....\n> ... So\n> perhaps we are better off to refer the user to git-log(1), say that\n> commit limiting options in general would work, but be careful with\n> sending a partial result.\n\nYou seem to have spelled out everything I originally wrote in my reply\nthat I later deleted before sending it out, and I think the reason that\nbrought you to the three-line conclusion is the same one that made me I\ndelete them ;-).\n\nUsing a partial patch essentially has the same risk as cherry-picking a\ncommit into different context, and it is a more generic issue that this\nparticular manual page should not waste tons of space to teach readers\nabout.  I think \"Be careful and clueful\" is sufficient and the best we can\ndo without writing a textbook on distributed software development\ndisciplines.\n\n> ... I tend to think the\n> commit-limiting options are the useful and working ones, which is why I\n> suggested mentioning them explicitly above.\n\nI think I agree that is a sane thing to do.\n"},{"id":"185379","messageId":"20120224211658.GA30922@sigill.intra.peff.net","threadId":"29705","inReplyTo":"7vk43cx7c2.fsf@alter.siamese.dyndns.org","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-24T21:16:58Z","receivedAt":"2012-02-24T21:16:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 24, 2012 at 01:14:05PM -0800, Junio C Hamano wrote:\n\n> > True. That is also a slightly dangerous thing to do, though, because you\n> > are omitting full patches in the middle that touch the same paths as the\n> > patches you include....\n> > ... So\n> > perhaps we are better off to refer the user to git-log(1), say that\n> > commit limiting options in general would work, but be careful with\n> > sending a partial result.\n> \n> You seem to have spelled out everything I originally wrote in my reply\n> that I later deleted before sending it out, and I think the reason that\n> brought you to the three-line conclusion is the same one that made me I\n> delete them ;-).\n\nOK, good. :)\n\nNikolaj, have you followed all of this? Do you want to try to improve\nyour patch in this direction?\n\n-Peff\n"},{"id":"185393","messageId":"201202242311.04787.jnareb@gmail.com","threadId":"29705","inReplyTo":"7vk43cx7c2.fsf@alter.siamese.dyndns.org","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-02-24T22:11:04Z","receivedAt":"2012-02-24T22:11:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jeff King <peff@peff.net> writes:\n> \n> > True. That is also a slightly dangerous thing to do, though, because you\n> > are omitting full patches in the middle that touch the same paths as the\n> > patches you include....\n> > ... So\n> > perhaps we are better off to refer the user to git-log(1), say that\n> > commit limiting options in general would work, but be careful with\n> > sending a partial result.\n> \n> You seem to have spelled out everything I originally wrote in my reply\n> that I later deleted before sending it out, and I think the reason that\n> brought you to the three-line conclusion is the same one that made me I\n> delete them ;-).\n> \n> Using a partial patch essentially has the same risk as cherry-picking a\n> commit into different context, and it is a more generic issue that this\n> particular manual page should not waste tons of space to teach readers\n> about.  I think \"Be careful and clueful\" is sufficient and the best we can\n> do without writing a textbook on distributed software development\n> disciplines.\n\nPerhaps git-format-patch should mention that it was created with\npath-limited patch in some email pseudo-header like X-Pathspec:\nor something, don't you think?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"185394","messageId":"7v7gzbhnoh.fsf@alter.siamese.dyndns.org","threadId":"29705","inReplyTo":"201202242311.04787.jnareb@gmail.com","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-24T22:27:42Z","receivedAt":"2012-02-24T22:27:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Perhaps git-format-patch should mention that it was created with\n> path-limited patch in some email pseudo-header like X-Pathspec:\n> or something, don't you think?\n\nWhat kind of workflow are you assuming, and who would benefit from such a\nheader under that assumption?\n\nIt obviously would not help the person who is running format-patch, as he\nis very well aware that he is giving a pathspec when he runs the command.\nIf the result is used privately to prepare a starting point of possibly\nunrelated work, it does not matter.\n\nIf you are assuming a workflow that involves a public review of mailed\npatches, it is very likely that such a header will be lost unless you are\nusing git-send-email, as we strongly discourage copying and pasting the\nentire thing in the message body.  Anybody sitting on the receiving end\nworth her salt would judge the submission by looking at the log message,\ndiffstat and the patch, and the sender having used pathspec to format the\npatch would not be a reason for rejection at all---the quality of the\nsubmission is.\n\nSo offhand, I do not know under what workflow such an extra header would\nbenefit people in what position in the workflow.\n"},{"id":"185986","messageId":"4F521F6E.2040602@gmail.com","threadId":"29705","inReplyTo":"20120224211658.GA30922@sigill.intra.peff.net","subject":"Re: git log -z doesn't separate commits with NULs","fromName":"Nikolaj Shurkaev","fromEmail":"snnicky@gmail.com","sentAt":"2012-03-03T13:41:02Z","receivedAt":"2012-03-03T13:41:02Z","isPatch":false,"sender":{"key":"snnicky@gmail.com","avatar":null},"body":"As far as I understood from what I read and from a brief look at source \ncode of git (builtin/log.c file) the best what we can do is just mention \nthat a lot of log options are applicable and warn user to use them with \nunderstanding of the consequences. I do not think that documentation of \nsome of options in Documentation/git-format-patch.txt makes sense \nbecause some of the options are connected one with another. For example \n--full-diff and <path> are connected as Junio C Hamano wrote. And that \ndependency is already explained in Documentation/git-log.txt.\n\nAnother option that I see is to put git-log options description into a \nseparate file and include that from git-log.txt and from \ngit-format-patch.txt like that is done with rev-list-options.txt. That \ncould be useful in a long term. Because new options may appear or some \nmay disappear. Some dependency between options may be documented. \nHowever for me that would require to get better understanding how all \nthat documentation is built. And that could require modifications of \ngit-log help also.\n\nPlease let me know how to proceed with that properly. Perhaps I should \nstart a separate discussion thread devoted to the documentation \nenhancement. Does thread subject matter?\n\nThank you.\n----------------------\ndiff --git a/Documentation/git-format-patch.txt \nb/Documentation/git-format-patch.txt\nindex 6ea9be7..d49ec80 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -68,6 +68,15 @@ If given `--thread`, `git-format-patch` will generate \n`In-Reply-To` and\n  as replies to the first mail; this also generates a `Message-Id` header to\n  reference.\n\n+NOTES\n+-----\n+\n+`git format-patch` and `git log` share significant part of their\n+implementations. As a result a lot of options available and described for\n+`git log` will work for `git format-patch` also. However it's required to\n+use them carefully with understanding of the consequences. For example\n+applying `<path>` option may make log messages irrelevant.\n+\n  OPTIONS\n  -------\n  :git-format-patch: 1\n\n\n25.02.2012 0:16, Jeff King пишет:\n> On Fri, Feb 24, 2012 at 01:14:05PM -0800, Junio C Hamano wrote:\n>\n>>> True. That is also a slightly dangerous thing to do, though, because you\n>>> are omitting full patches in the middle that touch the same paths as the\n>>> patches you include....\n>>> ... So\n>>> perhaps we are better off to refer the user to git-log(1), say that\n>>> commit limiting options in general would work, but be careful with\n>>> sending a partial result.\n>> You seem to have spelled out everything I originally wrote in my reply\n>> that I later deleted before sending it out, and I think the reason that\n>> brought you to the three-line conclusion is the same one that made me I\n>> delete them ;-).\n> OK, good. :)\n>\n> Nikolaj, have you followed all of this? Do you want to try to improve\n> your patch in this direction?\n>\n> -Peff\n>\n"}]}