git rebase - добавить оригинальный хеш для фиксации сообщений - PullRequest
0 голосов
/ 14 января 2019

Есть ли способ сделать то же самое, что и cherry-pick -x (добавить хеш исходного коммита к сообщению скопированного коммита) в ребазе?

В настоящее время я могу обойти это, заменив следующее

git checkout other-branch
git rebase master
git checkout master
git merge other-branch

с

git checkout master
....
git cherry-pick -x other-branch^^^^
git cherry-pick -x other-branch^^^
git cherry-pick -x other-branch^^
git cherry-pick -x other-branch^
git cherry-pick -x other-branch

Ответы [ 4 ]

0 голосов
/ 26 января 2019

опираясь на https://stackoverflow.com/a/54352290/5203563, Я закончил со скриптом, который выглядит так

#! /usr/bin/env bash

set -e

if [[ "$@" != "" ]];
then
    git rebase $@ --exec="$0"
    exit 0
fi

HASH="$(grep -o "\w\{40\}" .git/rebase-merge/done | tail -n1)"

git log --pretty="format:%B%n%nwas $HASH" -n1 | git commit --amend -F -

Я хотел избежать временных файлов. Первоначально я сделал это в двух сценариях, но затем объединил их в один с этой рекурсивной вещью, чтобы ее можно было легко разделить. Я назвал мой git-record, поэтому, если вы перейдете git record HEAD^^^^, он поместит текущие хеши во все коммиты (и изменит все хеши в процессе).

0 голосов
/ 24 января 2019

Это не красиво, но оно делает свою работу;

git rebase --exec='git log --pretty="format:%B" -n 1 > tmp;
    grep -o "\w\{40\}" .git/rebase-merge/done | tail -n 1 >> tmp; 
    git commit --amend -F tmp; 
    rm tmp;' master

Для объяснения каждой части сценария --exec;

  • Поместить сообщение о коммите, которое мы только что завершили, в tmp;
  • Получите хэш коммита, который мы только что перебазировали с .git/rebase-merge/done, и добавьте его к tmp.
  • Исправить только что сделанный нами коммит, используя tmp в качестве сообщения о коммите.
  • Удалить файл tmp.

Я уверен, что вы можете взломать это в формате, который вы найдете приятным.

Журнал оригинальной работы;

commit 1ebdfc2fd26b0eed9f131197dc3274f6d5048e97
Author: Adam
Date:   Thu Jan 24 16:33:09 2019 +0000

    Content C

commit 632f1a4e1ab5d47c9e4c3ca3abd02a207a5dda09
Author: Adam
Date:   Thu Jan 24 16:33:06 2019 +0000

    Content B

commit a7e0d1eb2e412ec51865ccd405ea513c7677c150
Author: Adam
Date:   Thu Jan 24 16:33:04 2019 +0000

    Content A

Журнал восстановленных работ;

commit 79d7ece06185b21631248a13416e5ca5c23e55b2
Author: Adam
Date:   Thu Jan 24 16:33:09 2019 +0000

    Content C
    1ebdfc2fd26b0eed9f131197dc3274f6d5048e97

commit d2fe6267165fa05f5fe489a6321b0b1742d1a74c
Author: Adam
Date:   Thu Jan 24 16:33:06 2019 +0000

    Content B
    632f1a4e1ab5d47c9e4c3ca3abd02a207a5dda09

commit da72fab2008e74f6a8e247f93619943805ebf86e
Author: Adam
Date:   Thu Jan 24 16:33:04 2019 +0000

    Content A
    a7e0d1eb2e412ec51865ccd405ea513c7677c150
0 голосов
/ 24 января 2019

Если вы просто используете rebase, чтобы сделать пакетную вишню, вы можете легко составить ее список выбора и делать вишневые грибы с любыми опциями, которые вы хотите:

batchxpickto() {
        local U=${1-@{u\}}      # given branch or default to configured upstream 
        local B=`git symbolic-ref -q --short HEAD`  # branch name to move if any
        local L=`git cherry $U.. | awk /^+/{print\$2}`  # commits to pick if any
        git checkout $U && ${L:+git cherry-pick -x $L}
        ${B:+git checkout -B $B}
}

используйте batchxpickto master так же, как и git rebase master.

Действительно, мне нравится ответ Адама лучше, но это альтернатива, и ее тактика может быть более полезной.

0 голосов
/ 18 января 2019

Итак, вот мое решение:

git rebase <branch> \
-ix "git rev-parse --short HEAD > tmp &&  \
echo 'from: $<branch_shortid>' > tmp && \
git commit --amend -F tmp"

Убедитесь, что branch_shortid правильно и сгенерировано в ветке, для которой вы хотите перебазировать контент из .

Отказ от ответственности: я не уверен, что это будет работать во всех случаях, особенно если у вас есть какие-то странные или сложные системы ссылок. Я запустил это на очень простом репозитории git, сгенерированном:

$ git init 
$ echo "a" > a.txt && git add . && git commit -m "first commit"
$ git checkout -b "feature1" 
$ echo "b" > b.txt && git add . && git commit -m "second commit"
$ echo "c" > c.txt && git add . && git commit -m "third commit"
$ feature1id=$(git rev-parse --short HEAD)
$ git checkout master
$ git rebase feature1 \
  -ix "git rev-parse --short HEAD > tmp &&  \
  echo 'from: $feature1_id' > tmp && \
  git commit --amend -F tmp"

Вот соответствующий вывод:

enter image description here


Обсуждение:

Как указывалось ранее, я думаю, что вы используете git reflog - лучшее решение для изучения того, из какого коммита, какая ветвь была объединена с желаемой.

Смысл перебазирования в том, чтобы применить коммиты к вершине другой ветви, как если бы это была структура коммитов:

Перебазирование создает линейную историю .

...