Re: [PATCHv2 1/2] rebase -i: optimize the creation of the todo file

From: Dominique Quatravaux <domq@google.com>
Date: Mar 9, 2012, 09:18 UTC
Message-ID: <CAJh6GrHMb-H6ktEGGHxMxbZXujKFe=unYzAyS-zoGnfzMfcKQA@mail.gmail.com>
In-Reply-To: <CAFfmPPMt_o1Rg-Pvuh_KpARrASwfYSq74UN3ayp=LVzLJ0oj=A@mail.gmail.com>

On Fri, Mar 9, 2012 at 6:00 AM, David Barr <davidbarr@google.com> wrote:

Show 8 quoted lines

> I do notice however that the output being fed to sed expands like so:
>
>  commit >634a5f265ad729b91266de65272e2b5a35d05b1c
>  >634a5f265ad729b91266de65272e2b5a35d05b1c 634a5f2 INSTALL: warn [...]
>  commit >828ea97de486c1693d6e4f2c7347acb50235a85d
>  >828ea97de486c1693d6e4f2c7347acb50235a85d 828ea97 Git 1.7.9
>
> Maybe the format spec and sed command could use a little tuning.

Hmm, from rev-list.c it appears that "oneline" is the only format that has git rev-list output one line per commit:

102 if (revs->commit_format == CMIT_FMT_ONELINE) 103 putchar(' '); 104 else 105 putchar('\n');

[...]

362 if (revs.commit_format == CMIT_FMT_ONELINE) 363 info.header_prefix = ""; 364 else 365 info.header_prefix = "commit ";

I could fix that by using "git log" instead (hence the erroneous log message for this patch, that I'll fix in the next attempt), but I don't know about the implications of that (semantic or performance-wise). On the other hand, I can't imagine how sed skipping every other "commit 12345abcdef" line could be a noticeable performance drain. Advice welcome.

-- 
  Dominique Quatravaux
  +41 79 609 40 72