Может ли `git reset -q` быть эквивалентным некоторой команде` git reset` без `-q`?

Question

Справочная страница git reset говорит

git reset [-q] [<tree-ish>] [--] <paths>…

Эта форма сбрасывает записи индекса для всех <paths> в их состояние по адресу <tree-ish>. (Это не влияет на рабочее дерево или текущий ответвление.) Это означает, что git reset <paths> противоположен git add <paths>.

Я думаю, что приведенная выше форма команды требует -q. Но означает ли [-q], что -q является необязательным? Если да, в чем отличие этой команды?

git reset [<mode>] [<commit>]

Эта форма сбрасывает текущую головку ветви на <commit> и, возможно, обновляет индекс (сбрасывая его на дерево <commit>) и рабочее дерево в зависимости от <mode>. Если <mode> опущено, по умолчанию --mixed.

Разве первая форма git reset -q HEAD [--] <paths>… не такая же, как

git reset mixed HEAD [--] <paths>…

Обратите внимание, что я считаю, что git reset [<mode>] [<commit>] можно добавить с [--] <paths>... в конце, потому что это показано в выходных данных следующей команды:

$ git rm feature2file 
rm 'feature2file'
$ git status
On branch feature2
Your branch is ahead of 'origin/feature2' by 2 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    feature2file

Answer 1

Флаг -q является необязательным и подразумевается непустой частью <paths>....Например:

git reset HEAD feature2file

имеет один аргумент <path>, а именно feature2file, поэтому подразумевается флаг -q.

... в чем его отличие... git reset [<mode>] [<commit>]

Эта команда, в которой отсутствуют аргументы <path>, вызывает другой режим работы git reset.

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

Разве первая форма git reset [-q] [<tree-ish>] [--] <paths>… не такая же, как git reset --mixed HEAD [--] <paths>…?

(Iисправил не пунктирную mixed, чтобы читать --mixed).Было бы , если бы последние были разрешены.Это, по крайней мере официально, не разрешено, но:

$ git reset --mixed HEAD -- Makefile
warning: --mixed with paths is deprecated; use 'git reset -- <paths>' instead.

Обратите внимание, что --hard и --soft исключены:

$ git reset --soft HEAD -- Makefile
fatal: Cannot do soft reset with paths.
$ git reset --hard HEAD -- Makefile
fatal: Cannot do hard reset with paths.

Случай --mixed,который является значением по умолчанию, если [<mode>] опущен, а [<commit>] является необязательным и по умолчанию HEAD, означает, что:

git reset hello

является неоднозначным:

• Делает ли этосоответствовать шаблону git reset [<mode>] [<commit>], где mode опущен (по умолчанию --mixed), а hello переведен в коммит с помощью правил из шести шагов в документации gitrevisions?Да, он точно соответствует этому шаблону.
• Соответствует ли он шаблону git reset [-q] [<tree-ish>] [--] <files>..., где <tree-ish> опущен, а <files> - имя файла hello?Да, он явно соответствует этому шаблону.

Какой из них git reset использует?Ответ таков: кодируется, чтобы опробовать оба, и если оба могут применить, выдают сообщение об ошибке:

fatal: ambiguous argument 'wt-status.c': both revision and filename
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

Эта проблема не возникла бы, если бы были разные команды для разныхрежимы работы.