Pas besoin de comprendre les références locales et distantes avec Hg
Non, mais tu ne vois 200 références dans ton historique graphique.
Tous les commits portent la même reference de branche et le tien c'est le commit courant checkouté.
Si tu veux les distinguer avec plusieur remote "hg path"
On peut pas « explorer » les remote hormis la branche active ?
Bien sûr que sin mais par défaut tu sais que su as n heads à réconcilier pas besoin d'aller les pécher ou d'utiliser les subtilités du shell ou le star-merge. Tous les commit portent le même nom de branche et pas remote1/mabranche remote2/mabranche.
Gnééé pourquoi expliquer le GC à des débutants ?
Pour leur expliquer pourquoi il faut faire gaffe lorsque qu'on fait un reset hard ou un chechout détaché. Si Mr GC passe avant de ressusciter son commmit non référencé adieu le commit. Et s'il ne passe pas ils se posent toujours la question de savoir où est passé leur code. Erreur de débutant classique
Sous hg pas moyen de voir l'historique remote à moins de pull ??
Hg pull = git fetch.
Pas besoin d'expliquer que le pull enchaîne automatiquement fetch+merge (au sens git merge ou git rebase).
Pas de rebase par défaut (c'est un plugin) et pas de config sur la branche pour pull (merge ou rebase).
Après, je ne sais pas comment est supporté le rebase aujourd'hui pour Hg
Je vois même pas ce qu'il y a à expliquer (à part le principe basique d'un outil de versionning, quoi)
Essaie d'expliquer à des gens venant de Cleracase ou SVN qu'un commande de merge, des fois elle merge des fois elle merge pas elle update.
Là encore, hg comprend magiquement ce que tu veux faire ?
Déjà y'a pas d'index par défaut avec Hg. Je l'avais oublié celle-là (Pas facile de convaincre de l'intérêt à des codeurs Java qui utilisent une vue Synchronise ou qui clique droit dans le projet et voientt les fichiers à commiter s'afficher déjà cochés et pas les autres.
Pis c'est tellement logique de rajouter à l'index pour marquer des conflit comme résolus pour des gens qui ont l'habitude d'utiliser un commande svn resolve, pour "resoudre" un conflit
Et après,
-- mixed, en fait ma bonne dame ca empile les commits intermédiaires et ca vous met ca dans le workspace
et --soft dans l'index, Logique.
Allez savoir pourquoi:
Ben parce que en plus --mixed, en plus il écrase l'index donc faut bien mettre ca queqpart.
J'hésite quoi penser : soit hg est vraiment très fort à tout deviner à ma place, soit on peut rien faire avec hg.
J'ai une 3e explication: une petite dose de mauvaise foi ?
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 4.
Non, mais tu ne vois 200 références dans ton historique graphique.
Tous les commits portent la même reference de branche et le tien c'est le commit courant checkouté.
Si tu veux les distinguer avec plusieur remote "hg path"
Pas besoin d'expliquer que le pull enchaîne automatiquement fetch+merge (au sens git merge ou git rebase).
Pas de rebase par défaut (c'est un plugin) et pas de config sur la branche pour pull (merge ou rebase).
Après, je ne sais pas comment est supporté le rebase aujourd'hui pour Hg
Déjà y'a pas d'index par défaut avec Hg. Je l'avais oublié celle-là (Pas facile de convaincre de l'intérêt à des codeurs Java qui utilisent une vue Synchronise ou qui clique droit dans le projet et voientt les fichiers à commiter s'afficher déjà cochés et pas les autres.
Pis c'est tellement logique de rajouter à l'index pour marquer des conflit comme résolus pour des gens qui ont l'habitude d'utiliser un commande svn resolve, pour "resoudre" un conflit
Et après,
-- mixed, en fait ma bonne dame ca empile les commits intermédiaires et ca vous met ca dans le workspace
et --soft dans l'index, Logique.
Allez savoir pourquoi:
Ben parce que en plus --mixed, en plus il écrase l'index donc faut bien mettre ca queqpart.