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
