Re: github

[Albert ARIBAUD <albert AT aribaud.net>]

Le jeudi 03 juin 2021 à 19:13 +0200, jdanield a écrit :
> Le 03/06/2021 à 18:48, Albert ARIBAUD (via linux-31 Mailing List) a
> écrit :
> 
> > - un dépôt peut avoir un dépôt distant uniquement pour le push ;
> > > - à ce sujet, un nom de remote est associé à *deux* URLs
> > > différentes, une pour le pull, une pour le pull. (je suppose pour
> > > le push?)
> > > 

(oui, une pour le pull, une pour le push)

> tu veux dire que dans certains cas on peut travailler en ligne (et
> pas en local) et sans doute aussi en local et pas en ligne
> 

La distinction entre commandes "en local" et commandes "en ligne" est
un fondamental de git, sauf que ce n'est pas "en local" vs "en ligne" :
par princpe l'activité git est uniquement locale, et seules deux
commandes impliquent un remote, les deux qui en ont un comme argument,
"git push" et "git pull" (et les soeurs de cette dernière comme "git
fetch").

Les deux URL associées à un remote, c'est juste qu'il y a des projets
pour lesquels "git pull" utilise une URL mais "git push" une autre.

> > En revanche, il est exact qu'on peut utiliser le nom d'un dépôt
> > distant à la place d'une URL, mais ça ne fonctionne pas n'importe
> > dans n'importe quelle commande : ce n'est pas juste "une variable".
> > 
> on joue sur les mots,  une variable n'a pas non plus de sens
> n'importe 
> où :-)

C'est précisément ce jeu, non pas sur, mais dans les mots que je pointe
: "une variable", sans contexte, peut être assimilée par exemple à une
variable Bash, d'autant plus que pour le coup le terme "variable"
existe bien dans Bash), alors que le même terme n'existe pas dans les
concepts git. Or, une variable Bash peut s'évaluer dans n'importe
quelle partie d'une commande bash, et du coup, assimiler un remote à
une variable risque de laisser l'impression à tort qu'il aurait la même
propriété.

> mais le problème de départ était que je ne sais pas donner login/mot
> de passe devant origin (ou autre), il me faut l'url complète.

L'URL complète est donnée quand on définit le remote, que ce soit par
"git clone" ou dans "git remote add". Une fois le remote créé dans le
dépôt local, il est associé à une identité et on ne change pas
d'identité ensuite. Mais pourquoi aurais-tu besoin de changer
d'identité ?

> Note que, pour l'instant je me concentre sur pmwiki, où les
> répertoires ne subissent aucune modification (c'est plus ou moins
> utilisé comme un ftp). Plus tard je verrai pour charlies, là c'est
> plus chaud, mais commençons par le plus simple.
> 

Mais il faut commencer par le plus simple *et* avec les bons
fondamentaux, sinon quand tu attaqueras charlies, çe sera avec de
mauvais biais qui n'auront pas été trop catastrophiques dans le cas
simple mais vont te rendre la tâche infiniment plus dure dans le cas
compliqué. :(

Par exemple, concernant "utiliser comme un FTP", ça peut être une façon
d'expliquer les remotes, *à condition* de savoir ce qui est transmis
dans ce "FTP" -- encore une fois, une analogie est utile pour le
principe général, mais pour la pratique, on a besoin d'aller au-delà,
et de ne pas aborder un nouvel outil en cherchant comment l'utiliser
comme ceux qu'on connaît déjà.

Par exemple, on sait tous comment fonctionnent des ciseaux ou un cutter
ou même un massicot, mais si on aborde l'usage d'une cliveuse à fibre
optique avec ce bagage de connaissances, on finit comme moi à foirer
les coupes pendant deux bonnes heures avant de prendre du recul,
oublier tout ce qu'on pense savoir pour pouvoir apprendre les
fondamentaux concrets. 

Une fois qu'on a compris que tout ce qu'on a à savoir sur les remotes,
le push, le pull (ou plutôt le fetch (plutôt que le) c'est que ça
*synchronise* les dépôts local et distant, et que du coup toutes les
commandes autres que ces trois-là n'opèrent *absolument pas depuis ou
sur le remote*, là on peut réaliser comment "envoyer un dossier"
proprement. Mais il *faut* ces bases.

> merci
> jdd
> -- 

Amicalement,
Albert.