Après le 1er pull
C résoud un conflit entre A et B et introduit une dépendance dans ton set,on a: e2={C->(A,B); E->D}
avec:
C
toto.txt
a
b
Dans e3 (l'autre user, on introduit un nouveau changement F ("b" devient "tadaa"). On a e3={F->B} avec;
F:
toto.txt
tadaa
Lorsqu'on pull dans e2 à nouveau on se retrouve avec: e2={C->(A,B); E->D, F->B} mais pour ton algo qui conserve un graphe de ligne même si B est une dépendance de C et F il ne considère pas ça comme un conflit est reconstruit la snapshot (le workspace) globale en :
toto.txt
a
tadaa
Il n'a pas besoin de construit un nouveau commit (automatiquement généré) pour le coup ?
Git évidemment se vautre car il a 1 3 way avec comme
base:
(un commit antérieur à ceux qui ont introduit a et b résolu lors du 1er conflit qui peut contenir a ou b ou aucun des 2)
[^] # Re: Exemples concrets?
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
Ok je crois que je je commence à piger.
Au départ on a
Après le 1er pull
C résoud un conflit entre A et B et introduit une dépendance dans ton set,on a:
e2={C->(A,B); E->D}
avec:
Dans e3 (l'autre user, on introduit un nouveau changement F ("b" devient "tadaa"). On a
e3={F->B} avec;
Lorsqu'on pull dans e2 à nouveau on se retrouve avec:
e2={C->(A,B); E->D, F->B} mais pour ton algo qui conserve un graphe de ligne même si B est une dépendance de C et F il ne considère pas ça comme un conflit est reconstruit la snapshot (le workspace) globale en :
Il n'a pas besoin de construit un nouveau commit (automatiquement généré) pour le coup ?
Git évidemment se vautre car il a 1 3 way avec comme
base:
(un commit antérieur à ceux qui ont introduit a et b résolu lors du 1er conflit qui peut contenir a ou b ou aucun des 2)
ours:
theirs:
Je vais tester tout ça.
Merci