git 2.7 (Q4 2015) introduira le tri des branches en utilisant directement git branch
:
voir commit aa3bc55 , commit aedcb7d , commit 1511b22 , commit f65f139 , ... (23 sept. 2015), commit aedcb7d , commit 1511b22 , commit ca41799 (24 sept. 2015), et commit f65f139 , ... (23 sept. 2015) par Karthik Nayak ( KarthikNayak
) .
(Fusionné par Junio C Hamano - gitster
- dans commit 7f11b48 , 15 oct.2015 )
En particulier, validez aedcb7d :
branch.c
: utiliser ' ref-filter
' API
Make « branch.c
» utilisation « ref-filter
» API pour Itère refs tri. Cela supprime la plupart du code utilisé pour le branch.c
remplacer par des appels à la ref-filter
bibliothèque ' '.
Il ajoute l'option--sort=<key>
:
Trier en fonction de la clé donnée.
Préfixe -
pour trier dans l'ordre décroissant de la valeur.
Vous pouvez utiliser l' --sort=<key>
option plusieurs fois, auquel cas la dernière clé devient la clé primaire.
Les clés prises en charge sont les mêmes que celles degit for-each-ref
.
L'ordre de tri par défaut est un tri basé sur le nom de référence complet (y compris le refs/...
préfixe). Cela répertorie d'abord HEAD détaché (si présent), puis les branches locales et enfin les branches de suivi à distance.
Ici:
git branch --sort=-committerdate
Ou (voir ci-dessous avec Git 2.19)
# if you are sure to /always/ want to see branches ordered by commits:
git config --global branch.sort -committerdate
git branch
Voir aussi commit 9e46833 (30 octobre 2015) par Karthik Nayak ( KarthikNayak
) .
Aidé par: Junio C Hamano ( gitster
) .
(Fusionné par Junio C Hamano - gitster
- en commit 415095f , 03 nov.2015 )
Lors du tri selon des valeurs numériques (par exemple --sort=objectsize
), il n'y a pas de comparaison de repli lorsque les deux références contiennent la même valeur. Cela peut entraîner des résultats inattendus (c'est-à-dire que l'ordre de listage des références avec des valeurs égales ne peut pas être prédéterminé) comme l'a souligné Johannes Sixt ( $ gmane / 280117 ).
Par conséquent, retour à la comparaison alphabétique basée sur le nom de référence chaque fois que l'autre critère est égal .
$ git branch --sort=objectsize
* (HEAD detached from fromtag)
branch-two
branch-one
master
Avec Git 2.19, l'ordre de tri peut être défini par défaut.
git branch
prend en charge une configuration branch.sort
, comme git tag
, qui avait déjà une configuration tag.sort
.
Voir commit 560ae1c (16 août 2018) de Samuel Maftoul (``) .
(Fusionné par Junio C Hamano - gitster
- dans commit d89db6f , 27 août 2018)
branch.sort:
Cette variable contrôle l'ordre de tri des branches lorsqu'elle est affichée par git-branch
.
Sans l' --sort=<value>
option " " fournie, la valeur de cette variable sera utilisée par défaut.
Pour répertorier les branches distantes, utilisez git branch -r --sort=objectsize
. L' -r
indicateur lui fait lister les branches distantes au lieu des branches locales.
Avec Git 2.27 (Q2 2020), les variantes " git branch
" et autres " for-each-ref
" acceptaient plusieurs --sort=<key>
options dans l'ordre croissant de priorité, mais il y avait quelques bris autour de la " --ignore-case
" gestion et bris d'égalité avec le refname, qui ont été corrigés.
Voir commit 7c5045f , commit 76f9e56 (03 mai 2020) par Jeff King ( peff
) .
(Fusionné par Junio C Hamano - gitster
- en commit 6de1630 , 08 mai 2020)
ref-filter
: appliquer le tri du nom de référence de secours uniquement après tous les tris utilisateur
Signé par: Jeff King
La validation 9e468334b4 (" ref-filter
: repli sur la comparaison alphabétique", 2015-10-30, Git v2.7.0-rc0 - fusion répertoriée dans le lot n ° 10 ) a enseigné au tri du filtre-ref de se replier sur la comparaison des noms.
Mais il l'a fait au mauvais niveau, remplaçant le résultat de la comparaison pour une seule --sort
clé " " de l'utilisateur, plutôt qu'après avoir épuisé toutes les clés de tri.
Cela fonctionnait correctement pour une seule --sort
option " ", mais pas pour plusieurs.
Nous rompions tout lien dans la première clé avec le nom de référence et n'évaluions jamais la deuxième clé.
Pour rendre les choses encore plus intéressantes, nous n'avons appliqué cette solution de rechange que parfois!
Pour un champ comme " taggeremail
" qui nécessite une comparaison de chaînes, nous retournerions vraiment le résultat de strcmp()
, même s'il était 0.
Mais pour les " value
" champs numériques comme " taggerdate
", nous avons appliqué le repli. Et c'est pourquoi notre test de tri multiple a raté cela: il utilise taggeremail
comme comparaison principale.
Commençons donc par ajouter un test beaucoup plus rigoureux. Nous aurons un ensemble de validations exprimant chaque combinaison de deux e-mails de tagueur, dates et refnames. Ensuite, nous pouvons confirmer que notre tri est appliqué avec la priorité correcte, et nous afficherons à la fois la chaîne et les comparateurs de valeurs.
Cela montre le bogue, et le correctif est simple: déplacer le repli sur la compare_refs()
fonction externe , après que toutes les ref_sorting
clés ont été épuisées.
Notez que dans la fonction externe, nous n'avons pas d' "ignore_case"
indicateur, car il fait partie de chaque ref_sorting
élément individuel . On peut se demander ce que devrait faire une telle solution de rechange, car nous n'avons pas utilisé les clés de l'utilisateur pour les faire correspondre.
Mais jusqu'à présent, nous avons essayé de respecter ce drapeau, donc la chose la moins invasive est d'essayer de continuer à le faire.
Étant donné que tous les appelants du code actuel définissent le drapeau pour toutes les clés ou pour aucune, nous pouvons simplement retirer le drapeau de la première clé. Dans un monde hypothétique où l'utilisateur peut vraiment inverser la sensibilité à la casse des clés séparément, nous pouvons vouloir étendre le code pour distinguer ce cas d'une couverture " --ignore-case
".