Git 2.7 (четвертый квартал 2015 года) представит сортировку ветвлений с использованием непосредственно git branch
:
см. commit aa3bc55 , commit aedcb7d , commit 1511b22 , commit f65f139 , ... (23 сентября 2015), commit aedcb7d , commit 1511b22 , commit ca41799 (24 Sep 2015) и commit f65f139 , ... (23 сентября 2015 г.) Картик Наяк ( KarthikNayak
) .
(Слиты Junio C Hamano - gitster
- в фиксации 7f11b48 , 15 окт 2015)
В частности, зафиксируйте aedcb7d :
branch.c
: используйте ref-filter
API
Сделать « branch.c
» использование « ref-filter
» API - интерфейсы для переборе рефов сортировки. Это удаляет большую часть кода, используемого в ' branch.c
', заменяя его вызовами к 'ref-filter
библиотеку '.
Это добавляет опцию--sort=<key>
:
Сортировка по ключу.
Приставка-
для сортировки в порядке убывания значения.
Вы можете использовать --sort=<key>
опцию несколько раз, и в этом случае последний ключ становится первичным ключом.
Поддерживаемые ключи такие же, как и вgit for-each-ref
.
Порядок сортировки по умолчанию сортируется на основе полного имени (включая refs/...
префикс). В нем сначала перечисляются отдельные HEAD (если есть), затем локальные ветви и, наконец, ветви с удаленным отслеживанием.
Вот:
git branch --sort=-committerdate
Или (см. Ниже с Git 2.19)
# if you are sure to /always/ want to see branches ordered by commits:
git config --global branch.sort -committerdate
git branch
Смотрите также коммит 9e46833 (30 октября 2015 г.) Картика Наяка ( KarthikNayak
) .
При поддержке: Junio C Hamano ( gitster
) .
(Слиты Junio C Hamano - gitster
- в фиксации 415095f , 3 ноября 2015)
При сортировке по числовым значениям (например --sort=objectsize
) нет запасного сравнения, когда обе ссылки содержат одно и то же значение. Это может привести к неожиданным результатам (т. Е. Порядок перечисления ссылок с одинаковыми значениями не может быть заранее определен), как указал Йоханнес Сикст ( $ gmane / 280117 ).
Следовательно, откат к алфавитному сравнению на основе refname всякий раз, когда другой критерий равен .
$ git branch --sort=objectsize
* (HEAD detached from fromtag)
branch-two
branch-one
master
С Git 2.19 порядок сортировки может быть установлен по умолчанию.
git branch
поддерживает конфиг branch.sort
, вроде git tag
, который уже был конфиг tag.sort
.
См. Коммит 560ae1c (16 августа 2018 г.) Самюэля Мафтула (``) .
(Слиты Junio C Hamano - gitster
- в фиксации d89db6f , 27 августа 2018)
branch.sort:
Эта переменная управляет порядком сортировки веток при отображении git-branch
.
Без --sort=<value>
предоставленной опции " " значение этой переменной будет использоваться по умолчанию.
Для просмотра удаленных веток используйте git branch -r --sort=objectsize
. -r
Флаг заставляет его в список удаленных филиалов вместо местных отделений.
В Git 2.27 (Q2 2020) варианты git branch
«и другие» for-each-ref
«принимали несколько --sort=<key>
вариантов в возрастающем порядке приоритета, но у него было несколько разрывов»--ignore-case
обработки " и разрывов связей с refname, которые были исправлены.
См. Коммит 7c5045f , коммит 76f9e56 (3 мая 2020 г.) Джеффа Кинга ( peff
) .
(Слиты Junio C Hamano - gitster
- в фиксации 6de1630 , 08 мая 2020)
ref-filter
: применять резервную сортировку refname только после всех пользовательских сортировок
Подписано: Джефф Кинг
Фиксировать 9e468334b4 ( « ref-filter
: Откат по алфавиту сравнения», 2015-10-30, Git v2.7.0-RC0 - слияние перечисленного в партии # 10 ) cортировать Преподавал реф-фильтр для Отката к сравнивающим refnames.
Но он сделал это на неправильном уровне, отвергая результат сравнения для одного "--sort
" ключа от пользователя, а не после того, как все ключи сортировки были исчерпаны.
Это работало правильно для одной --sort
опции " ", но не для нескольких.
Мы разорвали бы любые связи в первом ключе с refname и никогда не оценивали бы второй ключ вообще.
Чтобы сделать вещи еще более интересными, мы иногда применяем этот запасной вариант!
Для поля типа " taggeremail
", которое требует сравнения строк, мы действительно вернули бы результат strcmp()
, даже если бы он был 0.
Но для числовых " value
" полей типа " taggerdate
" мы применили запасной вариант. И именно поэтому наш тест множественной сортировки пропустил это: он использует taggeremail
в качестве основного сравнения.
Итак, давайте начнем с добавления гораздо более строгого теста. У нас будет набор коммитов, выражающих каждую комбинацию двух писем, дат и тегов. Затем мы можем подтвердить, что наша сортировка применяется с правильным приоритетом, и мы будем использовать как компараторы строк, так и значения.
Это действительно показывает ошибку, и исправление простое: перемещение запасного варианта во внешнюю compare_refs()
функцию после того, как все ref_sorting
ключи были исчерпаны.
Обратите внимание, что во внешней функции у нас нет "ignore_case"
флага, так как он является частью каждого отдельного ref_sorting
элемента. Это спорно , что такой запасной вариант должен делать, так как мы не использовали ключи пользователя в матч.
Но до сих пор мы пытались уважать этот флаг, поэтому наименее инвазивным является попытаться продолжать делать это.
Поскольку все вызывающие в текущем коде либо устанавливают флаг для всех ключей, либо для ни одного, мы можем просто извлечь флаг из первого ключа. В гипотетическом мире, где пользователь действительно может по отдельности переключать регистронезависимость клавиш, мы можем захотеть расширить код, чтобы отличать этот регистр от общего " --ignore-case
".