LINUX.ORG.RU
решено Форум — Development  

git replay

 , , ,


0

2

В git 2.44 добавлена экспериментальная команда git replay:

git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos too


SYNOPSIS
--------
(EXPERIMENTAL!) 'git replay' ([--contained] --onto <newbase> | --advance <branch>) <revision-range>...

DESCRIPTION
-----------

Takes ranges of commits and replays them onto a new location. Leaves
the working tree and the index untouched, and updates no references.
The output of this command is meant to be used as input to
`git update-ref --stdin`, which would update the relevant branches
(see the OUTPUT section below).

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.

When `--onto` is specified, the update-ref command(s) in the output will
update the branch(es) in the revision range to point at the new
commits, similar to the way how `git rebase --update-refs` updates
multiple branches in the affected range.

--advance <branch>
    Starting point at which to create the new commits; must be a
    branch name.

When `--advance` is specified, the update-ref command(s) in the output
will update the branch passed as an argument to `--advance` to point at
the new commits (in other words, this mimics a cherry-pick operation).

<revision-range>
    Range of commits to replay. More than one <revision-range> can
    be passed, but in `--advance <branch>` mode, they should have
    a single tip, so that it's clear where <branch> should point
    to. See "Specifying Ranges" in git-rev-parse and the
    "Commit Limiting" options below.

OUTPUT
------

When there are no conflicts, the output of this command is usable as
input to `git update-ref --stdin`.  It is of the form:

    update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
    update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
    update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}

where the number of refs updated depends on the arguments passed and
the shape of the history being replayed.  When using `--advance`, the
number of refs updated is always one, but for `--onto`, it can be one
or more (rebasing multiple branches simultaneously is supported).
★★★★★
← На чем сделать легковесный граф.редактор с кроссплатформой?
Определение названия и расположения слинкованной статически shared library в процесе исполнения. →
Ответ на: комментарий от EXL

Остаток. :)

EXAMPLES
--------

To simply rebase `mybranch` onto `target`:

------------
$ git replay --onto target origin/main..mybranch
update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH}
------------

To cherry-pick the commits from mybranch onto target:

------------
$ git replay --advance target origin/main..mybranch
update refs/heads/target ${NEW_target_HASH} ${OLD_target_HASH}
------------

Note that the first two examples replay the exact same commits and on
top of the exact same new base, they only differ in that the first
provides instructions to make mybranch point at the new commits and
the second provides instructions to make target point at them.

What if you have a stack of branches, one depending upon another, and
you'd really like to rebase the whole set?

------------
$ git replay --contained --onto origin/main origin/main..tipbranch
update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
update refs/heads/tipbranch ${NEW_tipbranch_HASH} ${OLD_tipbranch_HASH}
------------

When calling `git replay`, one does not need to specify a range of
commits to replay using the syntax `A..B`; any range expression will
do:

------------
$ git replay --onto origin/main ^base branch1 branch2 branch3
update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}
------------

This will simultaneously rebase `branch1`, `branch2`, and `branch3`,
all commits they have since `base`, playing them on top of
`origin/main`. These three branches may have commits on top of `base`
that they have in common, but that does not need to be the case.
dataman ★★★★★
() автор топика

Как я понимаю, это практически то же самое, что и git rebase --onto, но «leaves the working tree and the index untouched, and updates no references» и сохраняет состояние исходной ветки

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
26 февраля 2024 г.

Что ж, git 2.44 вышел, но статус экспериментальности у git replay остался:

~ $ git replay -h                                                                                                                                                                     usage: (EXPERIMENTAL!) git replay ([--contained] --onto <newbase> | --advance <branch>) <revision-range>...

    --[no-]advance <branch>
                          make replay advance given branch
    --[no-]onto <revision>
                          replay onto given commit
    --[no-]contained      advance all branches contained in revision-range
dataman ★★★★★
() автор топика
23 апреля 2024 г.

А в git 2.45 наконец-то

  • Integrate the reftable code into the refs framework as a backend. With «git init –ref-format=reftable», hopefully it would be a lot more efficient to manage a repository with many references.
dataman ★★★★★
() автор топика
← На чем сделать легковесный граф.редактор с кроссплатформой?
Development
Определение названия и расположения слинкованной статически shared library в процесе исполнения. →