Формулировка вопроса («перебазирован против ... чего-то другого») предполагает, что вы либо не уверены, либо не согласны с тем, что должен делать fork-point.Если мы начнем с четкого представления о том, что он делает (и если мы предполагаем, что он работает должным образом и не имеет разрушительных побочных эффектов), то мотивация для его использования по умолчанию может показаться более ясной.
(Честно говоря, я никогда не удосужился выяснить, что делает fork-point, прежде чем взглянуть на этот вопрос. Лучшее объяснение, кажется, содержится в документации git merge-base - https://git -scm.com/docs/git-merge-base.)
Перед тем, как попасть в сорняки, два "больших изображения" наблюдения:
1) Я не думаю, что разработчики git согласятсячто использование fork-point означает, что вы «опровергаете что-то другое»;Я думаю, что они, вероятно, сказали бы, что вы все еще сопротивляетесь восходящему потоку, но более разборчивы в отношении того, что обязывает переписывать на новой базе.
2) Хотя fork-point не всегда может быть полезным,Мне не ясно, по какому сценарию это может привести к исчезновению ваших коммитов [1].Было бы интересно увидеть любые минимальные тестовые случаи, которые показывают проблемы (поскольку выше я упомянул «не принимайте никаких деструктивных побочных эффектов» как условие думать, что это разумное значение по умолчанию).
Так что вдаваясь в это ...
Что пытается сделать точка ветвления?
Короткий ответ: если коммит ранее был частью восходящего потока и был удален из восходящего потока через историюedit, затем --fork-point говорит rebase оставить этот коммит на том основании, что (1) он на самом деле не является частью ветви, (2) он уже был отклонен из апстрима и (3) мы, вероятно, не пытаемсяотмените переписывание чьей-либо истории.
Это делается путем вывода информации из журналов.Поскольку reflogs являются локальными и временными, это немного клудж;Ваша попытка перебазирования может получить иной результат, чем попытка кого-то другого выполнить такую же перебазировку в, казалось бы, идентичном клоне репо.
И если ваши рефлоги, кажется, предполагают, что на самом деле ваш коммит был когда-точасть восходящего потока, это может вызвать проблемы.
Так зачем использовать его в качестве значения по умолчанию?
Я предполагаю, что суть в том, что разработчики предполагают, что если коммит был ранее в восходящем потоке и был удален извверх по течению, это удаление было окончательным.То, является ли это «обычно истиной», может зависеть от разработчика.
Странно то, что пример, используемый в merge-base документах (цитированных выше), кажется странным.Он показывает восходящий поток как origin/master, что подразумевает, что в какой-то момент master пульта дистанционного управления был переписан - что является ситуацией восстановления исходящего потока, которая обычно не рекомендуется.
По несвязанным причинам я нахожусь впривычка всегда указывать мой восходящий поток, когда я перебазирую.Это означает, что в зависимости от того, как вы на это смотрите, я упускаю выгоду и / или никогда не подвергаюсь риску выбора по умолчанию fork-point.
[1] Я сделалпридумать один потенциальный случай, но я не уверен, что это тот случай, с которым вы сталкиваетесь.Если вы являетесь мастером, и вы начинаете разработку функции, и только после фиксации вы понимаете, что забыли создать ветку функции;поэтому вы создаете ветку «на месте», а затем перематываете master, чтобы не вносить изменения;тогда перебазирование функции в master с помощью fork-point может сделать неправильную вещь.
Одним из решений, которое может помочь в этом случае, было бы, после перемотки master, вы могли бы сделать принудительную перебазировку для регенерации вашей ветви из свежих коммитовкоторые не находятся в главном журнале.