Hi Elijah, On Wed, 15 Jan 2020, Elijah Newren wrote: > On Sun, Jan 12, 2020 at 9:59 AM Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > > On Sat, 11 Jan 2020, Phillip Wood wrote: > > > > > On 11/01/2020 01:16, Elijah Newren wrote: > > > > > > > > On Fri, Jan 10, 2020 at 3:14 PM Jonathan Nieder > > > > <jrnieder@xxxxxxxxx> wrote: > > > > > > > 4. I suspect the exit status in the "you need to resolve conflicts" > > > > > case has changed. With rebase --am, [3] would automatically > > > > > invoke rebase --abort when conflicts are present, but with rebase > > > > > --merge it does not. > > > > > > > > > > Known? > > > > > > > > Nope, but I would certainly hope that "you need to resolve > > > > conflicts" would result in a non-zero exit status. If it doesn't, > > > > that sounds like a bug in the interactive backend that we need to > > > > fix. I'll dig in. > > > > Yes, exiting with status 0 would be a major bug, and I think it might > > even be a bug that was introduced by me when I re-implemented the core > > loop of the interactive rebase in C. > > Ooh, that sounds interesting. Do you have any more details? My simple > testing here shows that we exit with status 1, so we shouldn't have that > problem unless perhaps there was something else in next > (ra/rebase-i-more-options??) or some other special conditions that was > causing it. Oh, I did not mean to say that it exits with status 0. I meant to say that _if_ it does, it would be terrible, and that my suspicion would be that the re-implementation in C introduced that bug. But as you say, there is no bug, so for once, the re-implementation in C is not at fault! ;-) Ciao, Dscho
