Hi Duy, On Tue, 30 Jan 2018, Duy Nguyen wrote:
> On Mon, Jan 29, 2018 at 10:09 PM, Johannes Schindelin > <johannes.schinde...@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
