Re: [Q] rebase -i: turn "pick" to "edit", make no change, what should happen?

From: Sean Allred <allred.sean@gmail.com>
Date: May 17, 2024, 13:52 UTC
Message-ID: <m0eda0sfz7.fsf@epic96565.epic.com>
In-Reply-To: <233aefd10fbe965c190541d353822fe5@manjaro.org>

Dragan Simic <dsimic@manjaro.org> writes:

Show 17 quoted lines

> On 2024-05-17 09:32, Patrick Steinhardt wrote:
>> I quite frequently use "edit" just to inspect commits, stop at
>> random
>> points in the history, run tests and whatnot. So this would be a UX
>> regression for me because I do not want to change commit messages and
>> don't want to be bothered.
>> With the introduction of the "break" command you can certainly argue
>> that "edit" is the wrong command to use in my case. Muscle memory is
>> hard to retrain though :)
>> One could potentially make the behaviour configurable so that you
>> get to
>> choose how "edit" behaves.
>
> I agree that it would be best to introduce a new configuration option
> for this purpose.  Making such a change in the behavior of interactive
> rebase permanently would probably result in more than a few raised
> eyebrows, while a new configuration option would be a safe choice.

I would strongly disagree that new configuration would be best here. git-config isn't a silver bullet for finding a 'one size fits all' solution -- on the contrary, it usually only serves to confuse the community in situations where a decision should just have been made.

I've thought on this on and off and, were I asked the question 'what would you do if there were no precedent', I'd agree that 'edit' shouldn't simply be a shortcut for 'pick' then 'break'. Sequence editors are where such shortcuts should be implemented, IMO.

I want to be clear that I'm not saying the behavior *should* change at this point (at least not without the set of other breaking changes discussed elsewhere in the so-called Git 3.0 thread), but I can see why 'edit' having the behavior of invoking the editor every time would be desirable -- *because* each command should ideally have one clear job.

git-rebase(1) does briefly describe these commands, but perhaps not in a way that makes the relationship between them as clear as it could be:

       By replacing the command "pick" with the command "edit", you can
       tell git rebase to stop after applying that commit, so that you
       can edit the files and/or the commit message, amend the commit,
       and continue rebasing.

       To interrupt the rebase (just like an "edit" command would do,
       but without cherry-picking any commit first), use the "break"
       command.

       If you just want to edit the commit message for a commit, replace
       the command "pick" with the command "reword".

       To drop a commit, replace the command "pick" with "drop", or just
       delete the matching line.

..

I don't disagree that the behavior of 'edit' could change in a Git 3.0 and that such would be a positive change, but:

- such would be a breaking change -- I know of several tools that use
  interactive rebase in a scripted/non-interactive fashion
- introducing configuration to avoid the breaking change would, IMO,
  cause more harm than good. In my mind, it would be no different than
  having opt-in configuration to automatically staged everything when
  running git-commit.

-- 
Sean Allred