Каковы типичные случаи использования флагов git - reset --merge и --keep?

В недавнем ответе , в котором он подробно описывает типичные варианты использования git-reset трех наиболее часто используемых опций (--hard, --mixed и --soft), torek упоминает попутно, что git-reset также предлагает два относительно эзотерических флага, называемых --merge и --keep. git-reset man page описывает эти два флага следующим образом:

--merge

   Resets the index and updates the files in the working tree
   that are different between <commit> and HEAD, but keeps
   those which are different between the index and working tree
   (i.e. which have changes which have not been added). If a
   file that is different between <commit> and the index has
   unstaged changes, reset is aborted.

   In other words, --merge does something like a git read-tree
   -u -m <commit>, but carries forward unmerged index entries.

--keep
    Resets index entries and updates files in the working tree
    that are different between <commit> and HEAD. If a file that
    is different between <commit> and HEAD has local changes,
    reset is aborted.

Я прекрасно понимаю, когда использовать --hard, --mixed или --soft, но я узнал только, что --merge и --keep существовал при чтении ответа torek, и я не могу придумать практические примеры использования из этих двух флагов... В каких ситуациях вы обычно используете эти два флага?

В основном я ищу объяснение на простом английском языке. Возьмите следующий отрывок из этого ответа VonC, в котором описывается типичный пример использования git reset --soft в качестве модели:

[...] каждый раз:

  • вы удовлетворены тем, что у вас получилось (в терминах рабочего дерева и индекса)
  • вы не удовлетворены всеми коммитами, которые заставили вас туда добраться:

git reset --soft - ответ.

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

Ответы

Ответ 1

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

  • git reset --merge - новый режим, который работает аналогично git checkout переключает ветки с локальными изменениями переключение на другую фиксацию.

и --keep было добавлено в 1.7.1:

  • git reset узнал --keep вариант, который позволяет отменить фиксацию рядом с кончиком, сохраняя при этом локальные изменения способом, аналогичным как git checkout branch делает.

Тогда в 1.7.9:

  • git checkout -B <current branch> <elsewhere> является более интуитивным способ записать git reset --keep <elsewhere>.

который говорит нам, что идея --keep заключается в том, что вы начали работу над какой-то ветвью, а затем понимаете: oh, эта ветка должна откидываться от какой-то другой точки (вероятно, кончик какой-либо другой ветки). Например, вы можете:

$ git checkout devel
$ git checkout -b fix-bug-1234

а затем выполните некоторую работу по исправлению ошибки 1234 для следующей версии; но потом кто-то говорит: "Эй, нам нужна ошибка 1234, исправленная для старой версии!" Итак, теперь вы хотите fix-bug-1234 отделиться от release вместо devel. Между тем вы еще ничего не совершили. Итак, вы:

$ git checkout -B fix-bug-1234 release

чтобы переместить его в "спуск релиза" вместо того, чтобы "сходить с девела". Что работает в 1.7.9 или новее, но с 1.7.1 по 1.7.8 вы должны записать его git reset --keep.

Это может объяснить --keep, но --merge по-прежнему остается загадкой.