{"thread":{"id":"26520","subject":"[PATCH] git-patch-id.txt: show that you can pipe in git-log","startedAt":"2011-02-16T10:53:06Z","lastAt":"2011-02-16T22:24:10Z","messageCount":3,"participants":["Ævar Arnfjörð Bjarmason","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"161293","messageId":"1297853586-812-1-git-send-email-avarab@gmail.com","threadId":"26520","inReplyTo":null,"subject":"[PATCH] git-patch-id.txt: show that you can pipe in git-log","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-02-16T10:53:06Z","receivedAt":"2011-02-16T10:53:06Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Change the manual page for git-patch-id(1) to mention in the SYNOPSIS\nthat you can pipe in the git-log(1) output.\n\nThe manual page only mentioned that you could pipe in `< patch`, I had\nto grep the test suite to find that you could do things like `git log\n-p -1 | git patch-id`.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n Documentation/git-patch-id.txt | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt\nindex 4dae139..fec2cf3 100644\n--- a/Documentation/git-patch-id.txt\n+++ b/Documentation/git-patch-id.txt\n@@ -9,6 +9,8 @@ SYNOPSIS\n --------\n 'git patch-id' < \n \n+'git log --pretty=format:%H -p | git patch-id'\n+\n DESCRIPTION\n -----------\n A \"patch ID\" is nothing but a SHA1 of the diff associated with a patch, with\n-- \n1.7.2.3\n"},{"id":"161327","messageId":"7vaahvkc1o.fsf@alter.siamese.dyndns.org","threadId":"26520","inReplyTo":"1297853586-812-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH] git-patch-id.txt: show that you can pipe in git-log","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-16T19:35:31Z","receivedAt":"2011-02-16T19:35:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> Change the manual page for git-patch-id(1) to mention in the SYNOPSIS\n> that you can pipe in the git-log(1) output.\n>\n> The manual page only mentioned that you could pipe in `< patch`, I had\n> to grep the test suite to find that you could do things like `git log\n> -p -1 | git patch-id`.\n\nI tend to try to keep a command line example in the commit message from\ngetting split by rewording.\n\n The manual page only mentioned that you can redirect from a file\n with ` Signed-off-by: Ævar Arnfjörð Bjarmason \n> ---\n> Documentation/git-patch-id.txt | 2 ++\n> 1 files changed, 2 insertions(+), 0 deletions(-)\n>\n> diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt\n> index 4dae139..fec2cf3 100644\n> --- a/Documentation/git-patch-id.txt\n> +++ b/Documentation/git-patch-id.txt\n> @@ -9,6 +9,8 @@ SYNOPSIS\n> --------\n> 'git patch-id' < \n> \n> +'git log --pretty=format:%H -p | git patch-id'\n> +\n\nThe notation \"< \" is used as a way to say \"this command reads from\nits standard input and acts on it\". Anybody who understands what the\nredirection is knows that a normal command would not mind getting fed from\na pipe instead of a regular file (they _could_ tell the kind of file\ndescriptors, and there indeed are commands that change their behaviour\ndepending on the kind of file descriptor they are being fed from, but they\nare exceptions). So I don't think the new information should live here.\n\nIn a sense, I do not think the original is a material for SYNOPSIS\nsection, either. The first paragraph of DESCRIPTION section is also bad\nas a manual page; it doesn't say _what the command does_.\n\n> DESCRIPTION\n> -----------\n> A \"patch ID\" is nothing but a SHA1 of the diff associated with a patch, with\n\nHow about rewriting the whole thing, along these lines...\n\n\tSYNOPSIS\n\t--------\n 'git patch-id'\n\n DESCRIPTION\n -----------\n\tReads a patch from the standard input, and outputs the unique ID\n for it. When fed a series of patches that records which commit\n they come from (e.g. output from 'git format-patch --stdout' or\n 'git log -p'), reads them and outputs the unique IDs for them, one\n per line.\n\n\tA line in its output consists of two 40-byte hexadecimal values;\n\n 1. the unique ID for the change;\n 2. a SP; and\n 3. the commit object name for the change if known, or\n 40 \"0\" letters.\n\n\tA \"patch ID\" is nothing but a SHA-1 of ... (original text, but\n\tneeds to rewrite \"When dealing with...\" paragraph not to mention\n\tdiff-tree because that is not a user-facing command anymore).\n\n EXAMPLES\n --------\n\n\tgit patch-id wrote:\n> Ævar Arnfjörð Bjarmason   writes:\n\n> The notation \"< \" is used as a way to say \"this command reads from\n> its standard input and acts on it\".  Anybody who understands what the\n> redirection is knows that a normal command would not mind getting fed from\n> a pipe instead of a regular file (they _could_ tell the kind of file\n> descriptors, and there indeed are commands that change their behaviour\n> depending on the kind of file descriptor they are being fed from, but they\n> are exceptions).  So I don't think the new information should live here.\n\nYes, but see below.\n\n>>  DESCRIPTION\n>>  -----------\n>>  A \"patch ID\" is nothing but a SHA1 of the diff associated with a patch, with\n>\n> How about rewriting the whole thing, along these lines...\n>\n>        SYNOPSIS\n>        --------\n>        'git patch-id'\n>\n>        DESCRIPTION\n>        -----------\n>        Reads a patch from the standard input, and outputs the unique ID\n>        for it.  When fed a series of patches that records which commit\n>        they come from (e.g. output from 'git format-patch --stdout' or\n>        'git log -p'), reads them and outputs the unique IDs for them, one\n>        per line.\n>\n>        A line in its output consists of two 40-byte hexadecimal values;\n>\n>            1. the unique ID for the change;\n>            2. a SP; and\n>            3. the commit object name for the change if known, or\n>               40 \"0\" letters.\n>\n>        A \"patch ID\" is nothing but a SHA-1 of ... (original text, but\n>        needs to rewrite \"When dealing with...\" paragraph not to mention\n>        diff-tree because that is not a user-facing command anymore).\n>\n>        EXAMPLES\n>        --------\n>\n>        git patch-id \n>            ... (describe what this does) ...\n>\n>        git log -3 -p | git patch-id::\n>\n>            ... (describe what this does) ...\n\nThis looks much better.\n\nWhat I was aiming for was not to explain that:\n\n cat foo | thing\n thing < foo\n\nAre the same thing, but that nothing in git-patch-id's previous\nmanpage suggested that it could take a stream of commits, from reading\nit it looked like I would have to flush each individual patch to disk,\nthen feed them in one-by-one.\n\nBut your revised manpage explains that much better, you should commit\nit.\n"}]}