On Tuesday, 19 August 2025 12:56:02 CEST 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 > 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" > 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 > 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> > Same here about <revision> vs <commit>/<commit-ish>. Also, the form --(foo|bar) has never been used in synopsis. I think it would better be unrolled, just like in the description. Can you rename each occurrence of placeholder <revision> on the line so that the description can refer to them differently? > 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. with the renamed placeholders, this can be turned into something like: Move <commit> so that it becomes either the parent of <following-commit> or the child of <preceding-commit>.
