On Tue, Mar 10, 2020 at 01:58:12PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > The first change is that we'll now open an editor when continuing a > > conflicted rebase. You can see it by running this: > > ... > > We won't run the editor the "apply" backend, but do for "merge". I'm > > not sure how big a deal this is. > > Back when "git am" was written, it was not considered a bug that the > "git am --resolved" option did not offer the user a chance to update > the log message to match the adjustment of the code the user made, > but honestly, I'd have to say that it is a bug in "git am" in that > over time it wasn't adjusted to the new world order where we > encourage users to describe what they did when the automation > hiccuped by opening an editor. These days, even when automation > worked well (e.g. a clean auto-merge with "git merge"), we open an > editor. The world has changed, and so should the expectations. Thanks for writing this out. I had a general feeling that this wasn't a bug per se, but I agree with your argument that the behavior we want to end up with is the new one. It's unfortunate that it may cause some minor troubles for people upgrading, but that may be acceptable. We had a similar thing when "git merge" started opening an editor, I think. > If it were that we used to let the users edit and the new behaviour > is to auto-continue, it would be a quite drastic behaviour change > that may annoy the users, but fortunately this is the other way > around, so it may not be too bad. Having said all that, I do not > mind some workaround, e.g. "git rebase --continue --no-edit". > > "GIT_EDITOR=: git rebase --continue" would be a usable workaround > that does not require any code change, hopefully. Yeah, GIT_EDITOR=: works for me, but I agree that having a "--no-edit" option would be a little nicer. -Peff
