19 mai 2023

git: renommer master en main

Il est à la mode dans le monde git de renommer la branche historique 'master' en 'main'. D’ailleurs tous les services d'hébergement de git (BitBucket, GitHub, GitLab ...) nomment la branche par défaut des nouveaux repos 'main'. Voici comment effectuer cette migration techniquement inutile.

NB: Pour ceux et celles qui ont un MASTER (diplôme) je ne sais pas comment on fait, ni pour ceux qui roulent en Renault Master...


A) Celui (ou celle ...) qui a la responsabilité de faire la conversion des anciens repos devra exécuter les commandes suivantes pour chaque repo :

# S'il/elle n'a pas déjà une copie du repo à migrer il devra le cloner :
  $ git clone git@gitmachin.org:<user>/<repo>.git
  $ cd <repo>


# S'il/elle a déjà une copie :
  $ cd <repo>
  $ git checkout master

# Vérifier que l'on est bien par sur 'master'
  $ git status
  On branch master
  Your branch is up to date with 'origin/master'.

# Renommer localement 'master' en 'main' (ou tout autre nom qui ne choque la sensibilité de personne ...)
  $ git branch -m master main
  $ git status
  On branch main
  Your branch is up to date with 'origin/master'

# Pusher cette nouvelle branche sur 'origin' et la lier a origin/main(--set-upstream ou -u )
  $ git push --set-upstream origin main

Aller sur l’interface web de gitmachin et déclarer que 'main' est la nouvelle branche par défaut.
Sans cela l’étape suivante échouera.

# Supprimer de 'origin' la branche 'master'
  $ git push origin --delete master
      
# Vérifier
  $ git status
  On branch main
  Your branch is up to date with 'origin/main'.

 

NOTE: L'interface web des principaux hébergeurs de git propose de 

  • créer une nouvelle branche
  • modifier la branche par défaut
  • supprimer une branche (qui n'est pas celle par défaut)

Il est donc possible d'effectuer l’étape (A) uniquement avec la souris.


B) Tous les autres utilisateurs de ce repo devront exécuter ceci :

# S'assurer d’être sur la branche locale 'master'
  $ git checkout master


# Renommer localement de 'master' en 'main' (ou tout autre nom choisi à l’étape précédente)
  $ git branch -m master main

# Récupérer l'état actuel d'origin (ce qui inclue la nouvelle branche 'main')
  $ git fetch

# Supprimer le tracking de la branche distante 'master' qui n'existe plus.
  $ git branch --unset-upstream


# Lier la branche locale actuelle a origin/main
  $ git branch --set-upstream-to=origin/main

 

NOTE: Dans ce contexte, si vous utilisez Git 2.38 (Juillet 2020) une bonne pratique pour les repo créés localement est d’exécuter ceci :

$ git config --global init.defaultBranch main

25 avril 2023

Plusieurs comptes sur GitHub


Avant de répondre à la question de Comment gérer plusieurs comptes sur GitHub ? regardons comment GitHub effectue l'authentification.

1) Un seul utilisateur pour tout !

Vous l’avez très certainement remarqué quand vous interagissez avec GitHub vous utilisez toujours le user git. Par exemple :

git clone git@github.com:example/test

Pour accéder à des repositories publics ça ne parait pas surprenant, mais c’est aussi le cas quand on clone un repo privé. Comment github fait-il pour savoir si celui qui lance la commande a le droit d’accéder à ce repository ? Comme le user est toujours le même et qu’il n’y a pas de mot de passe, c’est forcément la clé ssh qui sert à la fois pour l’identification et l’authentification.

Cela implique qu’une même clé ssh ne peut être associée qu’à un seul profil. Si vous tentez de réutiliser une clé déjà associé à un profil vous aurez ce type d’erreur :

Verify public key failed for Example key is already in use.

2) A qui est cette clé ?

Bien sûr il est impossible que quelqu’un d’autre que vous ait la même clé. Si vous avez ce message d'erreur c'est que vous avez un (vieux...) profil qui utilise déjà cette clé. Pour savoir lequel, il suffit d’initier une connexion ssh en ligne de commande en explicitant la clé à utiliser :

ssh -T -ai ~/.ssh/id_rsa git@github.com

Si la clé est connue, la réponse de GitHub sera:

> Hi XXXXXX! You've successfully authenticated,
but GitHub does not provide shell access.

 Où XXXXX est le nom du profil utilisant cette clé.

3) Jongler avec les clés

Il faut donc avoir autant de clés ssh que de profils sur GitHub. Le problème est comment indiquer quand on fait une opération avec git quelle clé doit être utilisée ? Une fois de plus c’est le fichier ~/.ssh/config qui va nous sauver. 

Il faut créer un host fictif pour chaque profils en spécifiant au moins le véritable hostname et la clé à utiliser pour ce host.

cat ~/.ssh/config

Host Expl
    HostName github.com
    User git
    IdentityFile ~/.ssh/example_id_ed25519

Host Demo
    HostName github.com
    User git
    IdentityFile ~/.ssh/demo_id_rsa

 Grace à cela nous pourrons utiliser ces hosts fictifs ainsi :

git clone Expl:example/test
git clone Demo:demonstration/projet-demo

Le host fictif (Expl ou Demo) définit à la fois : le host réel (github.com), le user (git) et la clé à utiliser. Il n’est donc plus nécessaire de spécifier le user (git@Demo ou git@Expl). Il suffira donc de remplacer le classique « git@github.com » par Expl ou Demo suivant le profil que l’on veut utiliser.

    .ssh/config : Ref-1 , Ref-2

4) Confiez vos clés à un Agent-ssh

Une autre méthode consiste à charger toutes vos clés privées dans un agent ssh et laisser le protocole SSH essayer chaque clé jusqu’à ce que le serveur en accepte une. L'avantage d'un agent ssh est qu'il s'occupe de demander, si nécessaire, les pass-phrases des clés cryptées. Suivant l'agent il peut faire ça au démarrage, ou bien à la première utilisation de la clé.

- Un premier problème est que certains serveurs limitent le nombre de tentatives de connexion. Si vous avez beaucoup de clés chargées par l’agent-ssh vous risquez d’obtenir « too many authentication errors ».
- Le deuxièmes problème est quand vous avez plusieurs profils (donc plusieurs clés) sur GitHub . Comment savoir si la clé acceptée correspond au bon profil ?

Important: Pour que ssh interroge l'agent ssh il ne faut pas utiliser l'option  IdentitiesOnly dans .ssh/config

    Windows PuTTY/Pageant : Ref-1 , Ref-2 , Ref-3 
    Linux ssh-add et ssh-agent : Ref-4 , Ref-5

Résumons

Il y a trois sources possibles pour une clé privée:

a)     La clé par défaut id_rsa (ou id_ecdsa ou id_ed25519 etc…) venant du répertoire .ssh/
(méthode utilisable si on a une seule clé pour tout)

Dans les logs de  « ssh –T –v git@github.com » on trouvera cette paire de lignes Offering/Accepted :

Offering public key: C:\\Users\\bibi\\.ssh\\id_rsa RSA SHA256:GwKTTsGLCTlq…Ug
Server accepts  key: C:\\Users\\bibi\\.ssh\\id_rsa RSA SHA256:GwKTTsGLCTlq…Ug

b)     La clé associée explicitement au host fictif dans le fichier  .ssh/config
(méthode utilisable quand on doit associer une clé spécifique à certain host ou user@host)

Dans les logs de  « ssh –T –v example » on trouvera cette paire de lignes :
(rappel: example est une host fictif définit dans .ssh/config)

Offering public key: C:\\path\\to\\file RSA SHA256:GwKTTsGLCTlq…Ug explicit
Server accepts  key: C:\\path\\to\\file RSA SHA256:GwKTTsGLCTlq…Ug explicit

Notez le ‘explicit’ en fin de ligne.

c)     La clé proposée (parmi d’autres) par l’agent ssh :

Dans les logs de « ssh –T –v git@github.com » on trouvera cette paire de lignes :

Offering public key: nom_clé RSA SHA256:GwKTTsGLCTlq…Ug agent
Server accepts  key: nom_clé RSA SHA256:GwKTTsGLCTlq…Ug agent

Notez le ‘agent’ en fin de ligne.

SOLUTION

Il est évident qu’il faut de la méthode pour ne pas se mélanger les clés… 

- Le comportement par défaut de ssh n'est acceptable que si on a une une seule clé pour tout. Ce qui ne marche pas si vous avez plusieurs comptes GitHub.

- L'agent ssh est obligatoire quand les clés privées sont cryptées avec une pass-phrase. Dans ce cas il est fortement recommandé de le combiner avec la méthode suivante pour rendre le choix des clés prévisible.

- La méthode des hosts fictifs définis dans .ssh/config demande de la configuration et de modifier les url git pour éviter les ambiguités, mais c’est la seule méthode multi-clés dont le comportement est prévisible et sans risque de provoquer des « too many authentication errors ».


Donc ==>   .ssh/config  + (ssh-agent si pass-phrase)

L'utilisation du fichier .ssh/config donne accès à de très nombreuses options qui vont bien au delà du problème des profils multiples avec GiyHub.

https://www.openssh.com/


12 juin 2022

Qt & CMake : Add New File impossible !

Quand on crée un nouveau projet avec Qt on a le choix entre utiliser qmake, CMake ou Qbs comme gestionnaire de Build.

Qbs est déprécié depuis fin 2018, et devait disparaître avant 2020, mais en 2022 il est toujours disponible dans Qt 6 !

qmake et CMake sont donc les seuls à prendre en considérations. Malheureusement l’intégration dans Qt Designer n'est pas la même. malgré les promesses faites à l’annonce de la fin de Qbs:

Support for qmake will continue unaffected
Support for CMake will improve
Longer term, we plan to switch to CMake for building Qt itself
CMake support in Qt Creator will be further improved

En pratique, la syntaxe de CMake s'avère être trop compliquée à analyser et certaines fonctions nécessitant de modifier le fichier CMake ne sont pas active dans Qt Designer quand CMake est le gestionnaire de build.
Note: Celui qui affirme ça, Tobias Hunger, était l'un des principaux développeur de Qt Designer, et en particulier du build, de 2009 à 2020 (date du COVID et de son départ de Qt).

Exemple concret:

Une fois un projet créé avec  CMake (PRJ1_CM dans les copies d'écran ci dessous) il n'est pas possible d'utiliser les fonctions "Add Existing Files", "Add Existing Directory" et "Add Library". Alors que cela est possible avec qmake (PRJ2_QM dans les copies d’écrans), et même avec Qbs.

 

 PRJ1_CM utilise CMake

Un click bouton droit sur le nom du projet montre que les fonction "Add Existing Files / Directory / Library"  sont inactives (grisées)

 

 

 

 


 

 



 

 PRJ2_QM utilise qmake.

Tout fonctionne très bien avec qmake.

(avec Qbs aussi)

 

 

 

 

 

 

 

 

 

Vous noterez que même les icônes dans l’arborescence des projets CMake/qmake ne sont pas les mêmes. Les fichiers .ui (très important dans le développement d'un interface graphique) ne sont pas mis dans un groupe "Forms" spécifique comme c'est le cas avec qmake.

En résumé: tout dans le premier lien donné plus haut est faux; Qbs est toujours là et CMake n'est toujours pas mieux supporté.

Notes: Copies d’écran faite en juin 2022 avec Qt LTS 6.2.3 et Qt Designer 7.0.2