On Wed, Feb 16, 2011 at 20:35, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Ãvar ArnfjÃrà Bjarmason Â<avarab@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html