Hi Dscho, On Wed, Nov 8, 2023 at 1:47 PM Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > On Thu, 2 Nov 2023, Christian Couder wrote: > > + ## Documentation/git-replay.txt (new) ## > > +@@ > > ++git-replay(1) > > ++============= > > ++ > > ++NAME > > ++---- > > ++git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos too > > ++ > > ++ > > ++SYNOPSIS > > ++-------- > > ++[verse] > > ++'git replay' --onto <newbase> <revision-range>... # EXPERIMENTAL > > Technically, at this stage `git replay` requires precisely 5 arguments, so > the `<revision>...` is incorrect and should be `<upstream> <branch>` > instead. But it's not worth a new iteration to fix this. It was actually: 'git replay' --onto <newbase> <oldbase> <branch> # EXPERIMENTAL (you can see it there: https://lore.kernel.org/git/20231102135151.843758-3-christian.couder@xxxxxxxxx/) But I made a mistake in the range-diff command as I ran it against a previous development version instead of the current one. > > ++ > > ++DESCRIPTION > > ++----------- > > ++ > > ++Takes a range of commits and replays them onto a new location. > > ++ > > ++THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. > > ++ > > ++OPTIONS > > ++------- > > ++ > > ++--onto <newbase>:: > > ++ Starting point at which to create the new commits. May be any > > ++ valid commit, and not just an existing branch name. > > ++ > > Traditionally, this would be a place to describe the `<revision>` argument > (or, in this patch, to reflect the current state of `builtin/replay.c`, > the `<upstream> <branch>` arguments instead). I have fixed that in the v7 I just sent with the following: +SYNOPSIS +-------- +[verse] +'git replay' --onto <newbase> <oldbase> <branch> # EXPERIMENTAL + +DESCRIPTION +----------- + +Takes a range of commits, specified by <oldbase> and <branch>, and +replays them onto a new location (see `--onto` option below). + +THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. + Thanks for your review!
