Re: [PATCH] rebase --abort: cleanup refs/rewritten
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Apr 30, 2019, 22:49 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1904301848510.45@tvgsbejvaqbjf.bet>
- In-Reply-To
- <a3d5dd8c-12a6-a1d8-a41f-ef75c15df024@gmail.com>
Hi Phillip,
On Tue, 30 Apr 2019, Phillip Wood wrote:
Show 28 quoted lines
> On 29/04/2019 17:07, Johannes Schindelin wrote: > > > > On Fri, 26 Apr 2019, Phillip Wood wrote: > > > > > From: Phillip Wood <phillip.wood@dunelm.org.uk> > > > > > > When `rebase -r` finishes it removes any refs under refs/rewritten > > > that it has created. However if the rebase is aborted these refs are > > > not removed. This can cause problems for future rebases. For example I > > > recently wanted to merge a updated version of a topic branch into an > > > integration branch so ran `rebase -ir` and removed the picks and label > > > for the topic branch from the todo list so that > > > merge -C <old-merge> topic > > > would pick up the new version of topic. Unfortunately > > > refs/rewritten/topic already existed from a previous rebase that had > > > been aborted so the rebase just used the old topic, not the new one. > > > > > > Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> > > > --- > > > > Makes a ton of sense, and I feel a bit embarrassed that I forgot about > > that item on my TODO list. The patch looks obviously correct! > > Thanks, after I sent it I realized that --quit should probably clear > refs/rewritten as well, so I'll re-roll with that added. (One could argue that > a user might want them after quitting the rebase but there is no way to clean > them up safely once we've deleted the state files and I suspect most users > would be suprised if they were left laying around)
I am not so sure. `--quit` is essentially all about "leave the state as-is, but still abort the rebase".
So if I were you, I would *not* remove the `refs/rewritten/` refs in the `--quit` case.
Ciao, Dscho