Duy Nguyen <pclo...@gmail.com> writes: > On Thu, Oct 3, 2019 at 7:52 AM Junio C Hamano <gits...@pobox.com> 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.
