From: Patrick Steinhardt <ps@pks.im>
Date: Mon, 15 Sep 2025 09:33:59 GMT
Subject: Re: [PATCH RFC v3 00/18] Introduce git-history(1) command for easy history editing
Message-ID: <aMfdh8NxUj1v89Uu@pks.im>
In-Reply-To: <CABPp-BHeXtJPq7BE1UZ+zH0C-9VzQcSYRo+t0P-KWth68Zd94Q@mail.gmail.com>

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?
> I had envisioned having git-replay consolidate both cherry-pick and
> rebase functionality into one (then got pulled away by combination of
> work reassgniment & multiple life crises hitting at once taking my
> focus away for quite some time).  But now we're going in the other
> direction.  And further along that other direction is another extreme
> -- just having these be top-level commands, e.g. "git reorder", "git
> split", etc.

Yeah, we should consolidate from my point of view. With the current
status quo I'd say that:

  - git-replay(1) becomes the home for all plumbing-level functionality
    used by scripts and on the server-side.

  - git-history(1) becomes the home for history editing functionality
    that is user-facing. Potentially, we could also move (or rather
    alias) git-rebase(1) into git-history(1) to complete that vision at
    one point in time.

The main reason why I propose to introduce a top-level command with
different subcommands is that it helps users discover related
functionality. If we had "git reorder", "git split" et cetera as
separate subcommands it would be way harder for a user to find out "what
commands do I have to modify history?"

In the worst case, users can still create an alias for git-split(1).

> In a separate conversation we had (and I hope I'm paraphrasing
> correctly; if not please correct me), you mentioned you wanted
> git-history to be the home of history rewriting, and viewed git-replay
> as just a server side thing (whereas I created git-replay specifically
> as a user-focusing thing and then Christian changed it into a
> server-side thing since that part was complete and enough for his
> purposes).  But if git history is the home of history editing, how far
> does that go?  Do we have a "git history reset"?  "git history
> commit"?  "git history fast-export/fast-import"  "git history
> filter-repo"?  Or is it just the home for certain kinds of history
> rewriting operations?  If so, which ones?

My take in once sentence: git-history(1) modifies a preexisting sequence
of commits. With that definition we rule out:

  - "git history commit" because this creates a new commit on top.

  - "git history fast-export" because this doesn't edit the commit
    sequence.

  - "git history fast-import" because this imports nonexistent commits.

  - "git history reset" (which I assume is an alias of git-reset(1))
    because this command doesn't only care about commits, but it also
    modifies the working tree depending on the mode.

Something like "git history filter-repo" would probably be in the
picture though, as it matches the above definition.

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?

> That all said, I'm a big fan of the idea of incorporating more of jj
> capabilities, and you clearly marked the command as experimental
> (thanks!), which leave us room to adjust later if we don't like this
> path.  So I don't want to serve as a roadblock, I just think it's a
> useful conversation to have...

Definitely, thanks a lot for your thoughts!

Patrick