Thread (135 messages) flat view 135 messages, 9 authors, 2020-03-17

Re: [PATCH v3 15/15] rebase: change the default backend from "am" to "merge"

From: Johannes Schindelin <hidden>
Date: 2020-01-16 10:48:52

Hi Elijah,

On Wed, 15 Jan 2020, Elijah Newren wrote:
On Sun, Jan 12, 2020 at 9:59 AM Johannes Schindelin
[off-list ref] wrote:
quoted
On Sat, 11 Jan 2020, Phillip Wood wrote:
quoted
On 11/01/2020 01:16, Elijah Newren wrote:
quoted
On Fri, Jan 10, 2020 at 3:14 PM Jonathan Nieder
[off-list ref] wrote:
quoted
quoted
quoted
  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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help