Hi Duy,

On Tue, 30 Jan 2018, Duy Nguyen wrote:

> On Mon, Jan 29, 2018 at 10:09 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Hi Duy,
> >
> > On Fri, 26 Jan 2018, Nguyễn Thái Ngọc Duy wrote:
> >
> >> When a conflict happens during a rebase, you often need to look at the
> >> original patch to see what the changes are. This requires opening your
> >> favourite pager with some random path inside $GIT_DIR.
> >>
> >> This series makes that experience a bit better, by providing a command
> >> to read the patch. This is along the line of --edit-todo and --quit
> >> where you can just tell git what to do and not bother with details.
> >>
> >> My main focus is "git rebase", but because rebase uses "git am" behind
> >> the scene, "git am" gains --show-patch option too.
> >
> > Makes sense. I am not a 100% certain that 2/2 catches all rebase -i corner
> > cases, but I think the patches are good enough even for `next` already.
> 
> Not so fast :) With Tim's suggestion about using a pseudo ref and
> AEvar complaint about potential confusion, I might actually go with
> pseudo ref for rebase (and leave "git am" in the cold for now).

The pseudo ref certainly has an appeal. For people very familiar with
Git's peculiarities such as FETCH_HEAD. Such as myself.

For users, it is probably substantially worse an experience than having a
cmdmode like --show-patch in the very command they were just running.

Ciao,
Dscho