Disclaimer that I’ve never used Jujutsu. 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. > 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)? > 1610fe0 fifth > 444f97d third > 2f90797 second > b0ae659 fourth > bf7438d first > > $ git history reorder :/fourth --after=:/second > $ git log --oneline > c48729d fifth > f44a46e third > 26693b8 fourth > 8cb4171 second > bf7438d first > > Signed-off-by: Patrick Steinhardt <ps@xxxxxx> > --- > Documentation/git-history.adoc | 32 ++++++ > builtin/history.c | 135 +++++++++++++++++++++++++ > t/meson.build | 1 + > t/t3451-history-reorder.sh | 218 +++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 386 insertions(+) > > 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 > @@ -9,6 +9,7 @@ SYNOPSIS > -------- > [synopsis] > git history drop [<options>] <revision> > +git history reorder [<options>] <revision> --(before|after)=<revision> > > DESCRIPTION > ----------- > @@ -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/ ? > + > EXAMPLES > -------- >[snip]
