Re: [PATCH] git-patch-id.txt: show that you can pipe in git-log

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Feb 16, 2011 at 20:35, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> The notation "< <patch>" is used as a way to say "this command reads from
> its standard input and acts on it".  Anybody who understands what the
> redirection is knows that a normal command would not mind getting fed from
> a pipe instead of a regular file (they _could_ tell the kind of file
> descriptors, and there indeed are commands that change their behaviour
> depending on the kind of file descriptor they are being fed from, but they
> are exceptions).  So I don't think the new information should live here.

Yes, but see below.

>>  DESCRIPTION
>>  -----------
>>  A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with
>
> How about rewriting the whole thing, along these lines...
>
>        SYNOPSIS
>        --------
>        'git patch-id'
>
>        DESCRIPTION
>        -----------
>        Reads a patch from the standard input, and outputs the unique ID
>        for it.  When fed a series of patches that records which commit
>        they come from (e.g. output from 'git format-patch --stdout' or
>        'git log -p'), reads them and outputs the unique IDs for them, one
>        per line.
>
>        A line in its output consists of two 40-byte hexadecimal values;
>
>            1. the unique ID for the change;
>            2. a SP; and
>            3. the commit object name for the change if known, or
>               40 "0" letters.
>
>        A "patch ID" is nothing but a SHA-1 of ... (original text, but
>        needs to rewrite "When dealing with..." paragraph not to mention
>        diff-tree because that is not a user-facing command anymore).
>
>        EXAMPLES
>        --------
>
>        git patch-id <patch.txt::
>
>            ... (describe what this does) ...
>
>        git log -3 -p | git patch-id::
>
>            ... (describe what this does) ...

This looks much better.

What I was aiming for was not to explain that:

    cat foo | thing
    thing < foo

Are the same thing, but that nothing in git-patch-id's previous
manpage suggested that it could take a stream of commits, from reading
it it looked like I would have to flush each individual patch to disk,
then feed them in one-by-one.

But your revised manpage explains that much better, you should commit
it.