LINUX.ORG.RU

разделение git pull --rebase на онлайн и оффлайн составляющие

 


0

1

Цель: находясь онлайн быстро выкачать изменения для склонированных репозиториев, а потом оффлайн обновить их (что длится дольше из-за обычного hdd).

Вроде как

git pull --rebase
эквивалентен
git fetch
git rebase

Но есть и другое мнение.

По крайней мере о 100% эквивалентности точно говорить не приходится:

$ diff -rq 1-fetch-rebase/some-repo.git 1-pull-rebase/some-repo.git
Files 1-fetch-rebase/some-repo.git/.git/index and 1-pull-rebase/some-repo.git/.git/index differ
Files 1-fetch-rebase/some-repo.git/.git/logs/HEAD and 1-pull-rebase/some-repo.git/.git/logs/HEAD differ
Files 1-fetch-rebase/some-repo.git/.git/logs/refs/heads/master and 1-pull-rebase/some-repo.git/.git/logs/refs/heads/master differ
Files 1-fetch-rebase/some-repo.git/.git/logs/refs/remotes/origin/some-branch and 1-pull-rebase/some-repo.git/.git/logs/refs/remotes/origin/some-branch differ
Files 1-fetch-rebase/some-repo.git/.git/logs/refs/remotes/origin/master and 1-pull-rebase/some-repo.git/.git/logs/refs/remotes/origin/master differ
$

И это в простом случае, а если действительно upstream чего-то намудрит?

Кстати, а кто-нить встречал тесты для подобных хитрых изменений? Т.е. хэлпе и на stackoverflow встречаешь диаграммы коммитов, а есть ли готовые тестовые репозитории с этими коммитами?

Или если команды неэквивалентны, то это баг?

★★★★★

Но есть и другое мнение.

В «другом мнении» есть гипотетический мудак, который переписал историю.

bj ()
Ответ на: комментарий от bj

который переписал историю

Нехорошо. Но, значит, pull --rebase не является сокращением для двух других команд, что очень нехорошо.

gag ★★★★★ ()
Ответ на: комментарий от gag

pull --rebase делает rebase, а его результат зависит, как минимум, от времени, когда ты его сделал. поэтому даже два раза сделав rebase ты не получишь идентичных репозиториев.

maloi ★★★★★ ()
Ответ на: комментарий от gag

Но, значит, pull --rebase не является сокращением для двух других команд, что очень нехорошо.

В любом случае ребейз переписанной истории что через pull, что после fetch — занятие сомнительное. Я бы не выбирал какое говно пахнет лучше, а провел разъяснительную беседу с мудаком.

bj ()
Ответ на: комментарий от maloi

Да, действительно, временные отпечатки вносят погрешность в diff -rq. Но проблема игнорированием этих различий всё равно не решается.

gag ★★★★★ ()
Ответ на: комментарий от gag

я сходу могу сказать что кроме таймстемпов различаться будет reflog (по очевидным причинам), а ты, похоже, именно эти различия и показываешь в своем заглавном посте.

а вообще лучше бы ты привел пример когда (и чем) различаются working tree или что-то ещё значимое, а не просто сравнивал diff-ом репозитории.

maloi ★★★★★ ()
Ответ на: комментарий от maloi

а вообще лучше бы ты привел пример когда (и чем) различаются

Так вопрос в том, как этого наверняка избежать. Я ж автоматизированно обновляю склонированные репы. И для оптимизации процесса решил перейти с pull -rebase на fetch & rebase.

Вот был бы git metadiff, который как раз сравнивал бы метаданные двух реп.

gag ★★★★★ ()
Ответ на: комментарий от gag

Я ж автоматизированно обновляю склонированные репы.

Если ты их автоматизированно не меняешь, тогда зачем вообще rebase?

bj ()
Ответ на: комментарий от bj

Я бы не выбирал

Ну если дело только в выборе двух зол, тогда можно рискнуть.

gag ★★★★★ ()
Ответ на: комментарий от bj

Ну, чтоб наверняка.

Кстати, как-то раз после несколько недельного перерыва, одна репа отказалась git pull'оваться. Говорит, у меня там есть изменения. Жаль эксперимент с --rebase уже не проведёшь. Но странно как-то.

Да и повсюду пишут, если вы не upstream, используйте --rebase по-умолчанию.

gag ★★★★★ ()
Ответ на: комментарий от gag

Так вопрос в том, как этого наверняка избежать.

зачем? что ты хочешь этим добиться?

Я ж автоматизированно обновляю склонированные репы.

у тебя все равно будут различия из-за таймстемпов, почему ты хочешь избежать других различий?

Вот был бы git metadiff, который как раз сравнивал бы метаданные двух реп.

если ты работаешь с этими репозиториями, то эти метаданные в любом случае будут различаться, а если только синхронизируешь, то зачем тебе вообще --rebase?

maloi ★★★★★ ()
Ответ на: комментарий от gag

Кстати, как-то раз после несколько недельного перерыва, одна репа отказалась git pull'оваться. Говорит, у меня там есть изменения.

что за бред, он должен смержить твои изменения с upstream-ом, может быть git отказался push-ить, т.к. у тебя были не запулленые изменения?

maloi ★★★★★ ()
Ответ на: комментарий от maloi

зачем? что ты хочешь этим добиться?

Чтобы потом логи долго и нудно не изучать

у тебя все равно будут различия из-за таймстемпов, почему ты хочешь избежать других различий?

Люблю повторяемость, репродуцируемость. И не люблю, когда таймстемпы и прочая нерелевантная инфа мешают сравнению.

если ты работаешь с этими репозиториями, то эти метаданные в любом случае будут различаться, а если только синхронизируешь, то зачем тебе вообще --rebase?

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

Или если команды неэквивалентны, то это баг?

Кстати, так дока врёт или недоговаривает?

gag ★★★★★ ()
Ответ на: комментарий от gag

Кстати, так дока врёт или недоговаривает?

а ты доку читал или только рабинович напел? там все написано, хоть и слегка расплывчато. и повторю ещё раз - даже два rebase-а не будут гарантированно одинаковыми.

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

напиши патч, похоже, что пока это никому кроме тебя не нужно.

Люблю повторяемость, репродуцируемость. И не люблю, когда таймстемпы и прочая нерелевантная инфа мешают сравнению.

тогда не используй git так как ты используешь - он таймстемпы использует везде где можно.

maloi ★★★★★ ()
Ответ на: комментарий от gag

Кстати, как-то раз после несколько недельного перерыва, одна репа отказалась git pull'оваться. Говорит, у меня там есть изменения. Жаль эксперимент с --rebase уже не проведёшь. Но странно как-то.

Значит кто-то практикует git push -f на общем репозитории.

Dudraug ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.