Как собрать коммиты из 2-х разных локальных репозиториев в последовательную историю?

Question

[andmerk93]

Есть 2 локальных репозитория (one, two) с изменениями одного и того же файла.

Я делаю

cd one/
git remote add second ~/git_tests/two
git checkout --orphan second
git pull second second # во второй репе ветка называется second
git switch master
git merge second --allow-unrelated-histories
# решаю конфликты

git log --oneline --graph
# получаю

*   fd37a7e (HEAD -> second, master) Merge branch 'second'
|\  
| * bcf6d21 (second/second) fourth, "three"
| * 0f6a3f0 third, "two"
* d5c58d8 second, "two"
* fcc376b first, "one"


# а хочу добиться

*   fd37a7e (HEAD -> second, master) Merge branch 'second'
|\  
| * bcf6d21 (second/second) fourth, "three"
| * 0f6a3f0 third, "two"
|/
* d5c58d8 second, "two"
* fcc376b first, "one"

То есть я хочу указать у коммита 0f6a3f0 родительским коммитом d5c58d8
Как мне это сделать?

Comments

[Lynn «Кофеман»]

У вас тогда поменяются хеши 0f6a3f0 и bcf6d21.

А в чём смысл упражнения?

[maksam07]

Через rebase ?

[andmerk93]

Lynn «Кофеман»
> У вас тогда поменяются хеши 0f6a3f0 и bcf6d21
Если только это, то меня устроит. Мне надо, чтобы содержимое не менялось.

> А в чём смысл упражнения?
Это я тренируюсь на кошках.
Вообще, у меня есть проект, раскиданный по нескольким репозиториям, я хочу собрать сквозную историю коммитов.

maksam07
> Через rebase ?
Например, как?
Если это не изменит даты коммитов, то подойдёт.

[Сергей Кузнецов]

andmerk93,
Вы зачем-то построили несвязную историю (unrelated), а теперь пытаетесь её склеить ))
Почему нельзя было изначально работать над одной цепочкой коммитов и не плодить новые деревья?

То что вы хотите сделать, оно возможно. Делается путем пересоздания (rebase) цепочек коммитов (веток) одна поверх другой.
Получатся новые коммиты (с другим хешем), но визуально похожие со старыми. Будут те же изменения и те же даты и авторы. Как доберусь до компа, попробую написать вам развернутый ответ.

И называется это не последовательная, а связная история (related)

Answer 1

[Сергей Кузнецов]

git checkout --orphan second
git pull second second # во второй репе ветка называется second
git switch master
git merge second --allow-unrelated-histories
# решаю конфликты

Эти манипуляции можно заменить одной командой
git pull second second --allow-unrelated-histories
Результат будет идентичный.

хочу указать у коммита 0f6a3f0 родительским коммитом d5c58d8

Коммиты в гите неизменяемы. Если изначально родителя не было, то вы не прицепите его постфактум. Но вы можете пересадить ветку second на вершину master, пересобрав коммиты заново.

Чтобы получить что вам хочется, следует действовать иначе:

git fetch second # скачать все коммиты из второго репо
git switch second # перейти в ветку second
git rebase master # пересобрать ветку second с вершины ветки master
  dropping 0f6a3f0 third, "two" -- patch contents already upstream
  Successfully rebased and updated refs/heads/second.
git switch master # вернуться в master
git merge second --no-ff # влить second в master

Получим:

git log --oneline --graph
*   13dddb5 (HEAD -> master) Merge branch 'second'
|\
| * 515f80e (second) fourth, "three"
|/
* d5c58d8 second, "two"
* fcc376b first, "one"

Коммит third, "two" исчез из истории (дропнут) во время rebase, так как он полностью повторяет состояние second, "two"

Но если вам надо действительно последовательную историю, то не надо создавать коммит слияния. Не используйте ключ --no-ff в последней команде. Это просто установит указатель master на вершину.
И получится линейная история

git log --oneline --graph
* 515f80e (HEAD -> master, second) fourth, "three"
* d5c58d8 second, "two"
* fcc376b first, "one"

Comments

[andmerk93]

Да, то, что надо, спасибо!

Единственный момент, нужно добавить к rebase дополнительный ключ

git rebase master --committer-date-is-author-date

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

Подсмотрел тут - https://stackoverflow.com/questions/2973996/git-re...

Поправьте, пожалуйста, в своём ответе, я закрою вопрос.

[Сергей Кузнецов]

andmerk93, а зачем вы разными именами подписываете коммиты? (ЗЫ. тут я заблуждался)
У меня ничего не перебивается. Какие были даты, такие и остались.

В любом случае, метка автора не меняет дату. А когда коммит был пересобран разве так важно?

[andmerk93]

а зачем вы разными именами подписываете коммиты?

Ничего такого специально не делал. Все коммиты с одинаковой учеткой.

У меня ничего не перебивается. Какие были даты, такие и остались

У меня перебивается, не знаю, почему.
Ну, когда запрашиваешь git log он в Date старую отсавляет, но если запушить в гитхаб, или посмотреть в редакторе на локальной машине - показывает дату ребайса (нового коммита).

А когда коммит был пересобран разве так важно?

Как раз это неважно, важна исходная дата.
Её и фиксирует ключ "--committer-date-is-author-date", как я понял

[Сергей Кузнецов]

Как раз это неважно, важна исходная дата.
Её и фиксирует ключ "--committer-date-is-author-date", как я понял

Всё как раз наоборот. Почитайте ещё раз тот ответ на StackOverflow, там всё по полочкам разложено.
Там написано, что для сохранения даты автора ничего делать не нужно, это поведение по умолчанию.

Ключ --committer-date-is-author-date заставляет брать дату пересборки из даты изначального создания коммита.
Ключ --ignore-date делает противоположное. А именно, он стирает временные метки автора и заменяет их датой пересборки!

Ни то, ни другое вам не нужно.

Ничего такого специально не делал. Все коммиты с одинаковой учеткой.

Приведите доказательство. Покажите git log и там всё будет видно.
Скорее всего вы что-то путаете.

[andmerk93]

Ключ --committer-date-is-author-date заставляет брать дату пересборки из даты изначального создания коммита

Мне именно это и нужно

Приведите доказательство.

Пожалуйста.
Исходные коммиты из first - https://github.com/andmerk93/testrep
Коммиты из second, несвязная история - https://github.com/andmerk93/testrep/tree/unrelate...
Ребейс без ключа "committer-date-is-author-date" - https://github.com/andmerk93/testrep/tree/rebase-no-key
Ребейс с ключом "committer-date-is-author-date" - https://github.com/andmerk93/testrep/tree/rebase-w...

[Сергей Кузнецов]

Не вижу различий никаких

~\IdeaProjects\testrep git:[unrelated-history]
git log
commit bcf6d21998bdb3df548ef44d8321b1e992c73432 (HEAD -> unrelated-history)
Author: user <[e-mail]>
Date:   Thu May 16 21:55:27 2024 +0700

    fourth, "three"

~\IdeaProjects\testrep git:[rebase-no-key]
git log
commit 842e0ff7cac1dd83a96eb0ab5c4c7d56f19f22c9 (HEAD -> rebase-no-key)
Author: user <[e-mail]>
Date:   Thu May 16 21:55:27 2024 +0700

    fourth, "three"

~\IdeaProjects\testrep git:[rebase-with-key]
git log
commit 7a867a5debf72f8b0c34f08b3519c6bee72a81fb (HEAD -> rebase-with-key)
Author: user <[e-mail]>
Date:   Thu May 16 21:55:27 2024 +0700

    fourth, "three"

Дата пересозданного коммита не изменилась

[Сергей Кузнецов]

По-умолчанию гит выводит в лог только дату первоначального авторского коммита.
Вот так можно распечатать отдельно дату автора и дату пересборки:

git log --pretty=fuller -1
commit bcf6d21998bdb3df548ef44d8321b1e992c73432 (HEAD -> unrelated-history)
Author:     user <[e-mail]>
AuthorDate: Thu May 16 21:55:27 2024 +0700
Commit:     user <[e-mail]>
CommitDate: Thu May 16 21:55:27 2024 +0700

    fourth, "three"

git log --pretty=fuller -1
commit 842e0ff7cac1dd83a96eb0ab5c4c7d56f19f22c9 (HEAD -> rebase-no-key)
Author:     user <[e-mail]>
AuthorDate: Thu May 16 21:55:27 2024 +0700
Commit:     user <[e-mail]>
CommitDate: Tue May 21 19:10:45 2024 +0700

    fourth, "three"

git log --pretty=fuller -1
commit 7a867a5debf72f8b0c34f08b3519c6bee72a81fb (HEAD -> rebase-with-key)
Author:     user <[e-mail]>
AuthorDate: Thu May 16 21:55:27 2024 +0700
Commit:     user <[e-mail]>
CommitDate: Thu May 16 21:55:27 2024 +0700

    fourth, "three"

Это демонстрация работы ключа --committer-date-is-author-date
Без этого ключа коммит помнит дату когда его пересобрали — 21 мая.
Но вы сами сказали, что

это неважно, важна исходная дата

Видим, что исходная дата не меняется — 16 мая.

[andmerk93]

Сергей Кузнецов,
Я вас дезинформировал, мне нужна была не исходная дата, а дата создания коммита.
В следующий раз, когда буду задавать вопрос, обязательно выясню и уточню все имеющиеся термины.

Смотреть историю я, конечно же, собирался не в консоли, а в инструментах с графическим интерфейсом: гитхабе, гиткракене, и ИДЕшках. А они смотрят на дату создания коммита, а не на исходную.

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

[Сергей Кузнецов]

andmerk93, и вы снова вносите дезинформацию.
Исходная дата и дата создания это одно и то же.
Дата ПЕРЕсозданияя действительно меняется, но это никого не беспокоит почему то.
И гитхаб с IDE изначально показывают дату авторского коммита. Дата пересборки там лишь как дополнительный аттрибут иногда мелькает, и это никого совершенно не беспокоит.

[andmerk93]

> И гитхаб с IDE изначально показывают дату авторского коммита

Нет.

https://github.com/andmerk93/testrep/commits/rebas...


https://github.com/andmerk93/testrep/commits/rebas...

Answer 2

[andmerk93]

Ответ ниже от Сергей Кузнецов, я его немного исправил.

Коммиты в гите неизменяемы. Если изначально родителя не было, то вы не прицепите его постфактум. Но вы можете пересадить ветку second на вершину master, пересобрав коммиты заново.

Чтобы получить что вам хочется, следует действовать иначе:

git fetch second  # скачать все коммиты из второго репо
git switch second # перейти в ветку second
git rebase master --committer-date-is-author-date 
# пересобрать ветку second с вершины ветки master
# с заменой даты создания коммита
# для удобного отображения в редакторах
  dropping 0f6a3f0 third, "two" -- patch contents already upstream
  Successfully rebased and updated refs/heads/second.
git switch master         # вернуться в master
git merge second --no-ff  # влить second в master

Получим:

git log --oneline --graph
*   13dddb5 (HEAD -> master) Merge branch 'second'
|\
| * 515f80e (second) fourth, "three"
|/
* d5c58d8 second, "two"
* fcc376b first, "one"

Коммит third, "two" исчез из истории (дропнут) во время rebase, так как он полностью повторяет состояние second, "two"

Но если вам надо действительно последовательную историю, то не надо создавать коммит слияния. Не используйте ключ --no-ff в последней команде. Это просто установит указатель master на вершину.
И получится линейная история

git log --oneline --graph
* 515f80e (HEAD -> master, second) fourth, "three"
* d5c58d8 second, "two"
* fcc376b first, "one"

Answer 3

[Freeman]

Обычный cherry-pick, не? Слияние (merge) сливает ветку изменений целиком, а тут речь именно про ручной отбор, то есть собирание истории вручную?

git switch master

git cherry-pick second~1
# разрешаем конфликты, если надо
git cherry-pick --continue # если были конфликты

git cherry-pick second
# аналогично с конфликтами и продолжением

Аналогичного результата можно было бы добиться и при помощи перебазирования second на master, но оно приведет к нужному результату только если нет этих самых unrelated histories, ибо при их наличии начнет перетаскивать историю от сотворения мира. Для двух коммитов ручной перенос — самый простой и употребительный вариант, поменяется только дата коммита.

Comments

[andmerk93]

Нет, не то, это перебивает дату.

> Для двух коммитов ручной перенос — самый простой и употребительный вариант, поменяется только дата коммита

Это тренировочный репозиторий, который я сам себе сейчас сделал. Вообще у меня есть другие репы, где коммитов больше двух, и их нужно сшить. Черри-пикать поштучно всё ж не вариант.