Значение двойных дефисов Git checkout

Предположим, у меня есть файл с именем path/to/file.txt в моем репозитории Git, и я хочу отменить изменения в нем.

git checkout path/to/file.txt

Теперь предположим, что файл называется _3 _...

git checkout master

Ой! Вместо этого изменились ветки. Знак -- отделяет дерево, которое вы хотите извлечь, от файлов, которые вы хотите извлечь.

git checkout -- master

Также нам помогает, если какой-то урод добавил в наш репозиторий файл с именем -f:

git checkout -f      # wrong
git checkout -- -f   # right

Это задокументировано в git-checkout: устранение неоднозначности аргументов.

Двойное тире «-» означает «конец флагов командной строки», то есть указывает предыдущей команде не пытаться анализировать то, что идет после параметров командной строки.

Обратите внимание, что вам не понадобится, поскольку Git 2.5 (2 квартал 2015 г.) a '--', если ваш аргумент включает подстановочный знак (*)

Эвристика, помогающая соглашению командной строки «git <cmd> <revs> <pathspec>» обнаруживать ошибочные пути, заключается в том, чтобы убедиться, что все параметры, не относящиеся к rev, в более поздней части командной строки являются именами файлов в рабочем дереве, но это означает «_ 4_ "всегда следует устранять с помощью" -- ", потому что никто в здравом уме не создаст файл, имя которого буквально это звездочка-точка-см.

Git 2.5 теряет эвристику, чтобы объявить, что с подстановочной строкой пользователь, вероятно, хотел дать нам путь.

git checkout 'a*'
# same as
git checkout -- 'a*'

См. commit 28fcc0b (2 мая 2015 г.) по Дуй Нгуен (nguyenlocduy).
^{(Объединено Junio ​​C Hamano - gitster - в фиксации 949d167, 19 мая 2015 г.)}

pathspec: избегайте необходимости использовать "--" при использовании подстановочного знака

Когда в командной строке отсутствует "--" и команда может принимать как обороты, так и пути, идея заключается в том, что если аргумент может рассматриваться как как расширенный SHA-1, так и как путь, тогда требуется "--" или git отказывается продолжить.
В настоящее время он реализован как:

• (1) если аргумент rev, то он не должен существовать в рабочем дереве
• (2) иначе он должен существовать в рабочем дереве
• (3) в противном случае требуется "--".

Эти правила работают для буквальных путей, но когда используется нелитеральный pathspec, почти всегда требуется, чтобы пользователь добавлял «--», потому что он терпит неудачу (2), а (1) действительно редко встречается (возьмите, например, «*.c», ( 1) выполняется, если имеется ссылка с именем "*.c").

Этот патч немного изменяет правила, учитывая, что любой допустимый (*) путь с подстановочными знаками "существует в рабочем дереве".
Правила становятся:

• (1) если arg является rev, то он должен либо существовать в рабочем дереве, либо не быть допустимой спецификацией пути с подстановочными знаками.
• (2) иначе он либо существует в рабочем дереве, либо представляет собой спецификацию пути с подстановочными знаками
• (3) в противном случае требуется "--".

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

В Git 2.26 (первый квартал 2020 г.) логика устранения неоднозначности, позволяющая различать ревизии и спецификации пути, была изменена таким образом, что специальные символы glob с экранированием обратной косой черты не учитываются в правиле «подстановочные знаки являются указанием пути».

См. фиксацию 39e21c6 (25 января 2020 г.) по Джефф Кинг (peff).
^{(Объединено Junio ​​C Hamano - gitster - в совершить 341f8a6, 12 фев 2020)}

verify_filename(): обрабатывать обратные косые черты в правиле "подстановочные знаки - это пути"

^{Автор сообщения: Дэвид Бурстрём
Автор сообщения: Джефф Кинг}

Зафиксируйте 28fcc0b71a (pathspec: избегайте необходимости "--" при использовании подстановочного знака, 2015 г. -05-02) разрешено:

git rev-parse '*.c'

без двойного тире.

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

Если у вас есть такой файл на диске, вероятно, это то, что вы хотели.
Но если вы этого не сделаете, результаты будут сбивать с толку: вместо того, чтобы говорить «there's no such path a\b», мы спокойно примем его как путь, который, скорее всего, ничего не соответствует (или, по крайней мере, не тому, что вы планировали).
Аналогичным образом, поиск пути "a\*b" вообще не расширяет поиск; он найдет только одну запись "a*b".

Эта фиксация переключает правило на срабатывание только тогда, когда метасимволы глобуса расширяют поиск, что означает, что оба этих случая теперь сообщают об ошибке (вы все еще можете устранить неоднозначность, используя «--», конечно, мы просто усиливаем эвристику DWIM).

(DWIM: делай то, что я имею в виду)

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