Hi Christian, On Wed, 15 Nov 2023, Christian Couder wrote: > 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 Right. > > > ++ > > > ++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 I still think that the following would serve us better: [verse] (EXPERIMENTAL!) 'git replay' --onto <newbase> <oldbase> <branch> But if nobody else feels as strongly, I won't bring this up again. Ciao, Johannes
