Re: [PATCH v6 00/14] Introduce new `git replay` command

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Christian,

On Thu, 2 Nov 2023, Christian Couder wrote:

> # Range-diff between v5 and v6
>
> (Sorry it's very long mostly due to doc and test changes over a number
> of patches.)

I am grateful for the detailed range-diff that let's me focus exclusively
on what changed between iterations.

>  1:  72c34a0eba =  1:  fac0a9dff4 t6429: remove switching aspects of fast-rebase
>  2:  f85e6c823c !  2:  8a605ddef8 replay: introduce new builtin
>     @@ Commit message
>          For now, this is just a rename from `t/helper/test-fast-rebase.c` into
>          `builtin/replay.c` with minimal changes to make it build appropriately.
>
>     +    There is a stub documentation and a stub test script though.
>     +
>          Subsequent commits will flesh out its capabilities and make it a more
>          standard regular builtin.
>
>     @@ .gitignore
>       /git-rerere
>       /git-reset
>
>     + ## 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.

>     ++
>     ++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).

>     ++EXIT STATUS
>     ++-----------
>     ++
>     ++For a successful, non-conflicted replay, the exit status is 0.  When
>     ++the replay has conflicts, the exit status is 1.  If the replay is not
>     ++able to complete (or start) due to some kind of error, the exit status
>     ++is something other than 0 or 1.
>     ++
>     ++GIT
>     ++---
>     ++Part of the linkgit:git[1] suite
>     +
>       ## Makefile ##
> [... snipping non-controversial changes ...]
>  6:  37d545d5d6 !  6:  edafe4846f replay: change rev walking options
> [... snipping changes Elijah already talked about ...]
>  7:  2943f08926 =  7:  b81574744a replay: add an important FIXME comment about gpg signing
>  8:  f81962ba41 =  8:  b08ad2b2f1 replay: remove progress and info output
>  9:  236747497e !  9:  5099c94d2e replay: remove HEAD related sanity check
> {... snipping non-controversial changes ...]

Thank you!

Ciao,
Johannes





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux