Dragan Simic <dsimic@xxxxxxxxxxx> writes:
> 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
