Re: [PATCH RFC v3 00/18] Introduce git-history(1) command for easy history editing

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

On Mon, Sep 15, 2025 at 11:33:59AM +0200, Patrick Steinhardt wrote:
>On Sat, Sep 06, 2025 at 11:46:48PM -0700, Elijah Newren wrote:
>> So, this brings up a question.  Should we have git-rebase &
>> git-cherry-pick & git-replay & git-history, or should we consolidate?
>> [...]
>
>The main reason why I propose to introduce a top-level command with
>different subcommands is that it helps users discover related
>functionality.
>
i think this is better addressed with proper documentation.

>In the worst case, users can still create an alias for git-split(1).
>
it seems backwards to basically require aliases for efficient use. this
would also lead to a mismatch between what people write into how-tos and
what is actually in use (aliases are individual and therefore
inconsistent, so one needs to use the full form in writing).

>My take in once sentence: git-history(1) modifies a preexisting
>sequence of commits.
>
the details of this definition are arbitrary, and you already noticed
that there are grey areas. we will find more when we start looking for
them.

so, obviously, i'm in favor of atomizing.

>I was also wondering whether "git history" is too broad with that
>definition in mind. At one point in time I though about "git histedit"
>instead, which may be a bit of a better fit?
>
a natural name for this would be "revise", which, not coindicentally at
all, is actually an existing 3rd-party tool with a quite similar scope.
but then, see above.