Re: [PATCH/RFC] rebase: make resolve message clearer for inexperienced users

From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood@talktalk.net>
Cc: Philip Oakley <philipoakley@iee.org>,
	William Duclot <william.duclot@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH/RFC] rebase: make resolve message clearer for inexperienced users
Date: Mon, 24 Jul 2017 13:53:38 -0700	[thread overview]
Message-ID: <xmqqmv7td0a5.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <fd665e9d-e46a-c9f1-f4ec-3407dd18ab36@talktalk.net> (Phillip Wood's message of "Mon, 24 Jul 2017 10:51:57 +0100")

Phillip Wood <phillip.wood@talktalk.net> writes:

> git rebase --continue requiring one to git add first confuses/annoys me
> too. I started a patch to autostage unstaged changes if they don't
> contain conflict markers a couple of weeks ago, I'll clean it up and
> post it later this week.

As long as "git rebase" will keep refusing to start in a working
tree with dirty files and/or index, this could be a good change.

But people _may_ be annoyed because they expect "--continue" to
remind them that some conflicts are not concluded with an explicit
"git add", and they would even feel that you made the command unsafe
if "--continue" just goes ahead by auto-adding their change that is
still work-in-progress.  Lack of conflict markers is not a sign that
a file is fully resolved (which they are used to signal by "git
add", and they do so per set of paths).

> I also find it confusing that it asks me to edit the commit message for
> picks, fixups and non-final squashes after conflicts. I can see that
> perhaps one might want to amend the message to reflect any changes that
> were made while resolving the conflicts but I've never had too. I'd
> rather be able to pass --edit to rebase --continue if I needed to edit
> the message in those cases. Looking through the code I think it would
> require saving some extra state when rebase bails out on conflicts so
> rebase --continue could tell if it should be asking the user to amend
> the message.

This is disruptive if done without a careful transition plan and
you'll annoy existing users who expect to be able to edit by
default.  Especially since "rebase" keeps going and potentially
rebuild many commits on top, by the time they realize the mistake of
not passing "--edit", it is too late and they will hate you for
forcing them rebase many commits again.

If these suggestions above were given while "rebase -i" was
developed, it might have made the end-user experience a better one
than what it currently is, but transitioning after the current
behaviour has long been established makes it much harder.