Re: [PATCH] git-patch-id.txt: show that you can pipe in git-log
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Feb 16, 2011, 22:24 UTC
- Message-ID
- <AANLkTinbatY9KSr63K2sE-CP3r499Hvby8MOwdKq8WYU@mail.gmail.com>
- In-Reply-To
- <7vaahvkc1o.fsf@alter.siamese.dyndns.org>
On Wed, Feb 16, 2011 at 20:35, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 7 quoted lines
> 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.
Show 39 quoted lines
>> 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 < fooAre 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.