Subject: Re: [PATCH RFC 06/11] builtin/history: implement "reorder" subcommand

From: Patrick Steinhardt <[email-masked]>
Date: Sun, 24 Aug 2025 19:34:51 +0200

On Sun, Aug 24, 2025 at 07:25:48PM +0200, Kristoffer Haugsbakk wrote:
> On Tue, Aug 19, 2025, at 12:56, Patrick Steinhardt wrote:
> > When working in projects where having nice commits matters it's quite
> > common that developers end up reordering commits a lot. Tihs is
> 
> s/Tihs/This/
> 
> > typically done via interactive rebases, where they can then rearrange
> > commits in the instruction sheet.
> >
> > Still, this operation is a frequent-enough operation to provide a more
> > direct of doing this imperatively. As such, introduce a new "reorder"
> 
> s/direct of/direct way of/
> 
> What’s a use-case for doing this imperatively?  With a nice rebase
> frontend you get to shuffle around some lines in your preferred editor.
> This seems like using Ex mode in Vim.  Which is legitimate but I don’t
> quite see when you would do it.
> 
> The thing with e.g. the Drop subcommand is that I might have some
> commits marked `TEMP` that I wanna quickly drop at some point.  That’s
> sort of a semi-interactive use case; I might want to lightly script it,
> but I am always going to invoke it interactively.  Doing that light
> scripting on top of git-rebase(1) sounds like a hassle though.
> 
> But in this case I don’t understand when this would save you time over a
> nice Rebase frontend.  Because I don’t see when you want
> semi-interactive history reordering.

All I can say is that I ended up using this feature quite regularly with
Jujutsu. It sometimes just feels a less heavy-weight to tell Git what to
do directly instead of doing so via the editor.

Most often this happens when I just created a new smallish commit
because I noticed something and quickly want to reorder it somewhere
earlier.

> > subcommand where users can reorder a commit A to come after or before
> > another commit B:
> >
> >     $ git log --oneline
> >     a978f73 fifth
> >     57594ee fourth
> >     04eb1c4 third
> >     d535e30 second
> >     bf7438d first
> >
> >     $ git history reorder :/fourth --before=:/second
> >     $ git log --oneline
> 
> The `:/` notation makes sense here.  You’ve probably just made these
> commits so you want to match the newest ones.
> 
> Is this example meant to demonstrate how it works or to also demonstrate
> how you would use it (i.e. with revision syntax)?

Both, I guess. I often use this revision syntax myself, but in a lot of
other cases, especially when you just want to rebase HEAD, it may be
easier to just say "HEAD".

> > diff --git a/Documentation/git-history.adoc b/Documentation/git-history.adoc
> > index 3012445ddc..6e8b4e1326 100644
> > --- a/Documentation/git-history.adoc
> > +++ b/Documentation/git-history.adoc
> > @@ -40,6 +41,12 @@ Dropping the root commit converts the child of that
> > commit into the new
> >  root commit. It is invalid to drop a root commit that does not have any
> >  child commits, as that would lead to an empty branch.
> >
> > +reorder <revision> (--before=<revision>|--after=<revision>)::
> > +	Reorder the commit so that it becomes either the parent
> > +	(`--before=`) or child (`--after=`) of the other specified
> > +	commit. The commits must be related to one another and must be
> > +	reachable from the current `HEAD` commit.
> 
> s/current `HEAD` commit/current commit/ ?

Let's maybe say "currently checked-out commit".

Patrick