C'est pour Hg que je le regrette pardon.
Même si une extension existe.
Sinon je pense que je me suis mal exprimé.
Git n'accepte pas plusieurs commits concurrents pour une même branche (feuilles d'un graphe). Il y a une seule référence de branche qui pointe sur un unique commit.
Avec Hg plusieurs commits concurrents peuvent appartenir à la même branche. D'où la commande hg heads. Chaque commit porte et persiste le nom de la branche associée.
Résoudre des conflits ne nécessite que de connaitre le nom des branches.
Avec Git les évolutions concurrentes sont gérées en assignant une référence de branche à chaque remote (branches de suivi) et à la référence locale: la branche de travail, et en les mergeant. Cette association n'est qu'une pure convention (dépend des refspecs). Ceci est plus souple et ça permet de réallouer des synchronisations, mais c'est plus complexe à appréhender.
C'est d'ailleurs assez déconcertant pour les devs novices d'intégrer qu'il faille créer une branche locale (hormis clonage de branche) avant de pouvoir travailler dedans.
En revanche le fait de ne pas persister les références de branches dans les commits simplifie la gestion des branche locales (Juste une réference à supprimer).
[^] # Re: c'est une question de philosophie
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 1.
C'est pour Hg que je le regrette pardon.
Même si une extension existe.
Sinon je pense que je me suis mal exprimé.
Git n'accepte pas plusieurs commits concurrents pour une même branche (feuilles d'un graphe). Il y a une seule référence de branche qui pointe sur un unique commit.
Avec Hg plusieurs commits concurrents peuvent appartenir à la même branche. D'où la commande hg heads. Chaque commit porte et persiste le nom de la branche associée.
Résoudre des conflits ne nécessite que de connaitre le nom des branches.
Avec Git les évolutions concurrentes sont gérées en assignant une référence de branche à chaque remote (branches de suivi) et à la référence locale: la branche de travail, et en les mergeant. Cette association n'est qu'une pure convention (dépend des refspecs). Ceci est plus souple et ça permet de réallouer des synchronisations, mais c'est plus complexe à appréhender.
C'est d'ailleurs assez déconcertant pour les devs novices d'intégrer qu'il faille créer une branche locale (hormis clonage de branche) avant de pouvoir travailler dedans.
En revanche le fait de ne pas persister les références de branches dans les commits simplifie la gestion des branche locales (Juste une réference à supprimer).