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

From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date: Sep 16, 2025, 11:23 UTC
Message-ID: <aMlIseiqlfslrh9_@nubble.lan>
In-Reply-To: <aMfdh8NxUj1v89Uu@pks.im>

On Mon, Sep 15, 2025 at 11:33:59AM +0200, Patrick Steinhardt wrote:

Show 9 quoted lines

>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.