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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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