Re: [PATCH 0/2] Add "git rebase --show-patch"
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jan 30, 2018, 12:32 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1801301331410.35@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
- In-Reply-To
- <CACsJy8AH+xg3AB3qaqnFud4B8HHeyaO=8DqHL+p4HTTeSx6uYg@mail.gmail.com>
Hi Duy,
On Tue, 30 Jan 2018, Duy Nguyen wrote:
Show 23 quoted lines
> 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