Subject: Re: [BUG] incorrect line numbers reported in git am

From: Junio C Hamano <[email-masked]>
Date: Fri, 04 Oct 2019 07:56:11 +0900

Duy Nguyen <[email-masked]> writes:

> On Thu, Oct 3, 2019 at 7:52 AM Junio C Hamano <[email-masked]> wrote:
>> > In fact, running `git am --show-current-patch` shows the whole mail, not
>> > only the 'patch' file so users would have no reason to expect the line
>> > numbers to refer to the 'patch' file.
>>
>> Yeah, show-current-patch was a misguided attempt to hide useful
>> information from the users.
>
> Not so much hiding as not having the information to present, at least
> not the easy way, since the mail is split at the beginning of git-am
> and never stored in $GIT_DIR. By the time this command is run, the
> mail is already gone. Someone could of course update git-am to keep a
> copy of the mail and improve this option.

By "hiding", I meant "rob from the users an opportunity to learn
where the useful patch file is stored".  

You seem to be doubly confused in this case, in that (1) you seem to
have mistaken that I was complaining about show-current-patch not
giving the full information contained in the original e-mail, and
(2) you seem to think show-current-patch gives the contents of the
patch witout other e-mail cruft.  Both are incorrect.

The first thing the command does is to feed the input to mailsplit
and store the results in numbered files "%04d", and they are not
removed until truly done.  When you need to inspect the patch that
does not apply, they are still there.  Even emails for those steps
that have been successfully applied before the current one are also
there (the split files are all gone, though, but they no longer
matter as they have been applied fine).

I wouldn't have been so critical if "git am --show-current-patch"
were implemented as "cat $GIT_DIR/rebase-apply/patch", but it
does an equivalent of "cd $GIT_DIR/rebase-apply; cat $(cat next)"
which is much less useful when trying to fix up the patch text that
does not apply.