Какую команду выполнил git с "git reset --har"

Ответ 1

Это соответствует странице gitcli doc:

многие команды позволяют длинную опцию "-option" сокращаться только до их уникальный префикс (например, если нет другого варианта, чье имя начинается с "opt", вы можете записать "--opt", чтобы вызвать "-option" ), но вы должны полностью их прописать при написании ваши скрипты; более поздние версии Git могут ввести новый вариант, имя имеет тот же префикс, например. "--optimize", чтобы сделать короткий префикс который был уникальным, больше не уникален.

Также на той же странице:

Команды, поддерживающие расширенный парсер параметров, принимают уникальный префикс длинного варианта, как если бы он полностью прописан, но используйте это с помощью осторожность. Например, Git commit --amen ведет себя так, как если бы вы набрали gitcommit --amend, но это верно только до более поздней версии gitвводит другой вариант, который имеет один и тот же префикс, например `git commit --amenity ".

Итак, он побежал git reset --hard

Ответ 2

Он не выполнил эквивалент -h -a -r, потому что есть две предыдущие тире, а не одна.

Git может быть реализован алгоритм здесь, чтобы вы могли использовать кратчайшее уникальное совпадение для имени длинного флага. Поскольку длинные флаги для git reset начинаются с --har, он мог бы обработать запрос как однозначный и продолжить выполнение git reset --hard.

Ответ 3

В зависимости от вашего использования, не полагайтесь на сокращенные имена опций, которые предлагает API-интерфейс parse-options, чтобы защитить вас от сокращенной формы опции, которая раньше была уникальной в команде, становящейся неуникальной, когда новая опция, которая разделяет ту же самую добавлен префикс

См. Коммит b02e7d5 (12 апреля 2019 г.) и коммит effc2ba, коммит c4932b0, коммит f6188dc, коммит ae0a11c, коммит 7076e44, коммит f927ae6, коммит dd605e4 (25 марта 2019 г.) от Johannes Schindelin (dscho).
^{(Объединено Junio C Hamano - gitster - в коммите 39e4773, 22 апреля 2019 г.)}

tests: запретить использование сокращенных параметров (по умолчанию)

Парсеры командной строки Git поддерживают уникально сокращенные опции, например, git init --ba автоматически расширит --ba до --bare.

Это очень удобная функция в повседневной жизни пользователей Git, особенно когда закрытие вкладок недоступно.

Однако не стоит полагаться на это в тестовом наборе Git, поскольку то, что сегодня является уникальным сокращением параметра командной строки, может перестать быть уникальным сокращением завтра.

Например, если в будущем вклад добавлен новый режим git init --babyproofing а в ранее представленном тестовом примере использовался тот факт, что git init --ba расширился до git init --bare, то этот вклад в будущем теперь должен коснуться казалось бы, не связанные тесты только для того, чтобы избежать сбоя тестового набора.

Поэтому давайте по умолчанию запретим сокращенные параметры в наборе тестов.

Например:

tests (rebase): --keep-empty опцию --keep-empty

Этот тест хочет запустить git rebase --keep-empty опцией --keep-empty, но на самом деле он только прописал --keep и анализ доверенной опции Git, чтобы определить, что это было уникальное сокращение реального варианта.

Тем не менее, Denton Liu предоставил серию патчей, которая представляет новую опцию git rebase --keep-base под названием --keep-base, которая делает эту ранее уникальную аббревиатуру неуникальной.

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

Так что давайте просто не будем использовать сокращенные опции в наборе тестов.