git checkout permet de revenir à n'importe qu'elle version du fichie r:
$ git checkout commit -- file
récupère le fichier file dans la version ou il se trouvait à l'époque du
commit "commit" (on parle de commit avec git plus que de révisions).
En plus git possède des interfaces graphique comme gitk ou giggle qui
permette (entre autre) de ne regarder que les commits où un certain
fichier a évolué.
> Je tâtonne souvent et je crée des tas de versions différ entes d'un
> fichier; à la fin, soit le fichier final correspond à mes att entes, soit
> je pioche dans plusieurs pour obtenir le final - C'est toute cette cha îne
> que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me tro mpe
> ptêt: cette partie du dev est peut-être uniquement du ressort personnel et
> pas du système de VCS?)
git permet certainement de faire ça. Dans ce genre de cas ma mé thode est
de faire 36 branches correspondants au différentes idée que j'a i pour
résoudre le problème, et je choisi celle qui me va à la fi n, mais c'est
certainement pas la seul façon de faire.
git checkout permet de revenir à n'importe qu'elle version du fichie r:
$ git checkout commit -- file
récupère le fichier file dans la version ou il se trouvait à l'époque du
commit "commit" (on parle de commit avec git plus que de révisions).
En plus git possède des interfaces graphique comme gitk ou giggle qui
permette (entre autre) de ne regarder que les commits où un certain
fichier a évolué.
> Je tâtonne souvent et je crée des tas de versions différ entes d'un
> fichier; à la fin, soit le fichier final correspond à mes att entes, soit
> je pioche dans plusieurs pour obtenir le final - C'est toute cette cha îne
> que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me tro mpe
> ptêt: cette partie du dev est peut-être uniquement du ressort personnel et
> pas du système de VCS?)
git permet certainement de faire ça. Dans ce genre de cas ma mé thode est
de faire 36 branches correspondants au différentes idée que j'a i pour
résoudre le problème, et je choisi celle qui me va à la fi n, mais c'est
certainement pas la seul façon de faire.
git checkout permet de revenir à n'importe qu'elle version du fichie r:
$ git checkout commit -- file
récupère le fichier file dans la version ou il se trouvait à l'époque du
commit "commit" (on parle de commit avec git plus que de révisions).
En plus git possède des interfaces graphique comme gitk ou giggle qui
permette (entre autre) de ne regarder que les commits où un certain
fichier a évolué.
> Je tâtonne souvent et je crée des tas de versions différ entes d'un
> fichier; à la fin, soit le fichier final correspond à mes att entes, soit
> je pioche dans plusieurs pour obtenir le final - C'est toute cette cha îne
> que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me tro mpe
> ptêt: cette partie du dev est peut-être uniquement du ressort personnel et
> pas du système de VCS?)
git permet certainement de faire ça. Dans ce genre de cas ma mé thode est
de faire 36 branches correspondants au différentes idée que j'a i pour
résoudre le problème, et je choisi celle qui me va à la fi n, mais c'est
certainement pas la seul façon de faire.
est il possible de savoir si les clients sont win32 ou uniquement
GNU ...
est il possible de savoir si les clients sont win32 ou uniquement
GNU ...
est il possible de savoir si les clients sont win32 ou uniquement
GNU ...
On Sat, 30 Apr 2011 17:57:47 +0200, Rémi Vanicat w rote:
...git checkout permet de revenir à n'importe qu'elle version du fichier:
$ git checkout commit -- file
récupère le fichier file dans la version ou il se trouvait à l'é poque du
commit "commit" (on parle de commit avec git plus que de révisions).
Ha, meilleur!
Pour être sur d'avoir bien compris:
$ git checkout a8445d2551ca45ef -- monfichieramoiquejeveuxdanscecommit
et ça roule?En plus git possède des interfaces graphique comme gitk ou giggle qui
permette (entre autre) de ne regarder que les commits où un certain
fichier a évolué.
Je n'avais testé que gitk, je vais retester avec giggle
> Je tâtonne souvent et je crée des tas de versions différentes d' un
> fichier; à la fin, soit le fichier final correspond à mes attentes , soit
> je pioche dans plusieurs pour obtenir le final - C'est toute cette cha îne
> que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me tr ompe
> ptêt: cette partie du dev est peut-être uniquement du ressort pers onnel et
> pas du système de VCS?)
git permet certainement de faire ça. Dans ce genre de cas ma méthode est
de faire 36 branches correspondants au différentes idée que j'ai pou r
résoudre le problème, et je choisi celle qui me va à la fin, mais c'est
certainement pas la seul façon de faire.
ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de
toutes les modifs d'un fichier jusqu'au commit final)
On Sat, 30 Apr 2011 17:57:47 +0200, Rémi Vanicat <vanicat@debian.org> w rote:
...
git checkout permet de revenir à n'importe qu'elle version du fichier:
$ git checkout commit -- file
récupère le fichier file dans la version ou il se trouvait à l'é poque du
commit "commit" (on parle de commit avec git plus que de révisions).
Ha, meilleur!
Pour être sur d'avoir bien compris:
$ git checkout a8445d2551ca45ef -- monfichieramoiquejeveuxdanscecommit
et ça roule?
En plus git possède des interfaces graphique comme gitk ou giggle qui
permette (entre autre) de ne regarder que les commits où un certain
fichier a évolué.
Je n'avais testé que gitk, je vais retester avec giggle
> Je tâtonne souvent et je crée des tas de versions différentes d' un
> fichier; à la fin, soit le fichier final correspond à mes attentes , soit
> je pioche dans plusieurs pour obtenir le final - C'est toute cette cha îne
> que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me tr ompe
> ptêt: cette partie du dev est peut-être uniquement du ressort pers onnel et
> pas du système de VCS?)
git permet certainement de faire ça. Dans ce genre de cas ma méthode est
de faire 36 branches correspondants au différentes idée que j'ai pou r
résoudre le problème, et je choisi celle qui me va à la fin, mais c'est
certainement pas la seul façon de faire.
ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de
toutes les modifs d'un fichier jusqu'au commit final)
On Sat, 30 Apr 2011 17:57:47 +0200, Rémi Vanicat w rote:
...git checkout permet de revenir à n'importe qu'elle version du fichier:
$ git checkout commit -- file
récupère le fichier file dans la version ou il se trouvait à l'é poque du
commit "commit" (on parle de commit avec git plus que de révisions).
Ha, meilleur!
Pour être sur d'avoir bien compris:
$ git checkout a8445d2551ca45ef -- monfichieramoiquejeveuxdanscecommit
et ça roule?En plus git possède des interfaces graphique comme gitk ou giggle qui
permette (entre autre) de ne regarder que les commits où un certain
fichier a évolué.
Je n'avais testé que gitk, je vais retester avec giggle
> Je tâtonne souvent et je crée des tas de versions différentes d' un
> fichier; à la fin, soit le fichier final correspond à mes attentes , soit
> je pioche dans plusieurs pour obtenir le final - C'est toute cette cha îne
> que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me tr ompe
> ptêt: cette partie du dev est peut-être uniquement du ressort pers onnel et
> pas du système de VCS?)
git permet certainement de faire ça. Dans ce genre de cas ma méthode est
de faire 36 branches correspondants au différentes idée que j'ai pou r
résoudre le problème, et je choisi celle qui me va à la fin, mais c'est
certainement pas la seul façon de faire.
ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de
toutes les modifs d'un fichier jusqu'au commit final)
parce que je procède en tâtonnant, et que des fois il m'est arrivé de modifier
un fichier et de m'apercevoir qu'une des versions précédentes était
"meilleure"
> A mon avis, tu n'as pas assez expliqué ton besoin, et surtout le genre
> de projet pour lequel tu veux un versionneur. Si on tente de deviner en
> aveugle, on ne peut pas aider.
C'est un ERP écrit en python (parce que malheureusement, le port de wx dans
wxLUA n'a pas intégré le côté virtuel des fonctions que j'utilise le plus,
comme wxCtrlList)
parce que je procède en tâtonnant, et que des fois il m'est arrivé de modifier
un fichier et de m'apercevoir qu'une des versions précédentes était
"meilleure"
> A mon avis, tu n'as pas assez expliqué ton besoin, et surtout le genre
> de projet pour lequel tu veux un versionneur. Si on tente de deviner en
> aveugle, on ne peut pas aider.
C'est un ERP écrit en python (parce que malheureusement, le port de wx dans
wxLUA n'a pas intégré le côté virtuel des fonctions que j'utilise le plus,
comme wxCtrlList)
parce que je procède en tâtonnant, et que des fois il m'est arrivé de modifier
un fichier et de m'apercevoir qu'une des versions précédentes était
"meilleure"
> A mon avis, tu n'as pas assez expliqué ton besoin, et surtout le genre
> de projet pour lequel tu veux un versionneur. Si on tente de deviner en
> aveugle, on ne peut pas aider.
C'est un ERP écrit en python (parce que malheureusement, le port de wx dans
wxLUA n'a pas intégré le côté virtuel des fonctions que j'utilise le plus,
comme wxCtrlList)
ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de
toutes les modifs d'un fichier jusqu'au commit final)
ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de
toutes les modifs d'un fichier jusqu'au commit final)
ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de
toutes les modifs d'un fichier jusqu'au commit final)
Ce que tu dis est malheureusement ce que j'avais compris lors de différents
tests: tu est limité à toute l'arborescence, sans pouvoir descendre au niveau
fichier, à moins que de rétablir *toute* la branche antérieure voulue - ce qui
ne correspond pas à mes attentes (juste un fichier par-ci par-là.)
Ce que tu dis est malheureusement ce que j'avais compris lors de différents
tests: tu est limité à toute l'arborescence, sans pouvoir descendre au niveau
fichier, à moins que de rétablir *toute* la branche antérieure voulue - ce qui
ne correspond pas à mes attentes (juste un fichier par-ci par-là.)
Ce que tu dis est malheureusement ce que j'avais compris lors de différents
tests: tu est limité à toute l'arborescence, sans pouvoir descendre au niveau
fichier, à moins que de rétablir *toute* la branche antérieure voulue - ce qui
ne correspond pas à mes attentes (juste un fichier par-ci par-là.)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/04/2011 16:10, Bernard Schoenacker a écrit :
> est il possible de savoir si les clients sont win32 ou
> uniquement GNU ...
Git est un vrai bordel à installer «proprement» sous win.
Pour un DSCM à la fois Linux et Windows, j'aurais tendance à plutôt
partir sur du Mercurial, surtout si c'est pour le moment du dev en
local qui peut migrer sur du dev distant.
SVN est globalement à éviter.
Même s'il reste extrêmement utilisé (mais pour des raisons historiques
et non de performances), il montre les limites des «mauvais» choix
techniques utilisés (matérialisation des tags et des branches, faibles
performances sur les branch/merge, utilisation d'un serveur
centralisé…). Autre problème, le manque flagrant d'amélioration des
fonctionnalités (comme l'amélioration de la gestion des rename/move
qui est extrêmement problématique) depuis un long moment déjà.
- --
Aeris
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/04/2011 16:10, Bernard Schoenacker a écrit :
> est il possible de savoir si les clients sont win32 ou
> uniquement GNU ...
Git est un vrai bordel à installer «proprement» sous win.
Pour un DSCM à la fois Linux et Windows, j'aurais tendance à plutôt
partir sur du Mercurial, surtout si c'est pour le moment du dev en
local qui peut migrer sur du dev distant.
SVN est globalement à éviter.
Même s'il reste extrêmement utilisé (mais pour des raisons historiques
et non de performances), il montre les limites des «mauvais» choix
techniques utilisés (matérialisation des tags et des branches, faibles
performances sur les branch/merge, utilisation d'un serveur
centralisé…). Autre problème, le manque flagrant d'amélioration des
fonctionnalités (comme l'amélioration de la gestion des rename/move
qui est extrêmement problématique) depuis un long moment déjà.
- --
Aeris
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/04/2011 16:10, Bernard Schoenacker a écrit :
> est il possible de savoir si les clients sont win32 ou
> uniquement GNU ...
Git est un vrai bordel à installer «proprement» sous win.
Pour un DSCM à la fois Linux et Windows, j'aurais tendance à plutôt
partir sur du Mercurial, surtout si c'est pour le moment du dev en
local qui peut migrer sur du dev distant.
SVN est globalement à éviter.
Même s'il reste extrêmement utilisé (mais pour des raisons historiques
et non de performances), il montre les limites des «mauvais» choix
techniques utilisés (matérialisation des tags et des branches, faibles
performances sur les branch/merge, utilisation d'un serveur
centralisé…). Autre problème, le manque flagrant d'amélioration des
fonctionnalités (comme l'amélioration de la gestion des rename/move
qui est extrêmement problématique) depuis un long moment déjà.
- --
Aeris
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/04/2011 18:20, Jean-Yves F. Barbier a écrit :
> ben d'après ce que j'ai compris, si (enfin si je veux garder les
> traces de toutes les modifs d'un fichier jusqu'au commit final)
Non, tu veux garder les traces de tous les commits d'un fichier
jusqu'au tag final =)
Tout SCM aura besoin que tu commites tes fichiers pour en suivre les
modifications. Il n'y a pas de sauvegarde en temps réel (sauf à être
sur du VMS :þ).
- --
Aeris
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/04/2011 18:20, Jean-Yves F. Barbier a écrit :
> ben d'après ce que j'ai compris, si (enfin si je veux garder les
> traces de toutes les modifs d'un fichier jusqu'au commit final)
Non, tu veux garder les traces de tous les commits d'un fichier
jusqu'au tag final =)
Tout SCM aura besoin que tu commites tes fichiers pour en suivre les
modifications. Il n'y a pas de sauvegarde en temps réel (sauf à être
sur du VMS :þ).
- --
Aeris
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/04/2011 18:20, Jean-Yves F. Barbier a écrit :
> ben d'après ce que j'ai compris, si (enfin si je veux garder les
> traces de toutes les modifs d'un fichier jusqu'au commit final)
Non, tu veux garder les traces de tous les commits d'un fichier
jusqu'au tag final =)
Tout SCM aura besoin que tu commites tes fichiers pour en suivre les
modifications. Il n'y a pas de sauvegarde en temps réel (sauf à être
sur du VMS :þ).
- --
Aeris
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/04/2011 18:20, Jean-Yves F. Barbier a écrit :
> ben d'après ce que j'ai compris, si (enfin si je veux garder les trac es de
> toutes les modifs d'un fichier jusqu'au commit final)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/04/2011 18:20, Jean-Yves F. Barbier a écrit :
> ben d'après ce que j'ai compris, si (enfin si je veux garder les trac es de
> toutes les modifs d'un fichier jusqu'au commit final)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/04/2011 18:20, Jean-Yves F. Barbier a écrit :
> ben d'après ce que j'ai compris, si (enfin si je veux garder les trac es de
> toutes les modifs d'un fichier jusqu'au commit final)
Je confirme. Et d'ailleurs, c'est une règle de base dans les gros
projets collaboratifs (comme GCC). On commit des *petites*
modifications, souvent de quelques lignes ou douzaines de lignes.
Par exemple, sur GCC (versionné avec SVN), il y a 173221 commits dep uis
son origine (dans les années 1985?). Et les 5 derniers (obtenus par
svn log --limit 5) sont!
Comme tu peux le voir, les développeurs de gcc commettent des petits
patchs le plus souvent (quelques dizaines de lignes modifiées par co mmit).
Il peut arriver que la description du commit (c'est à dire l'entrà ©e dans
un ChangeLog) soit presque aussi grosse que le changement commis.
C'est aussi dû à la règle sociale de GCC: on ne peut y com mettre que du
code qui a été revu et approuvé par autrui.
Et même sur un développement où je suis tout seul, je comm ite plusieurs
fois par jour. Le temps entre deux commit, c'est le temps éléme ntaire
qu'on accepte de perdre. On a donc intérêt à ce qu'il ne s oit pas trop
long.
C'est aussi un avantage de GIT sur SVN: il sait faire des branches
facilement et il sait commiter rapidement.
En gros, je commite souvent après correction d'un seul bogue ou ajout
d'une seule fonction ou méthode (notamment quand elle est publique), ou
ajout de quelques douzaines de lignes au maximum. Je commite toujours
avant de partir (manger, ou chez moi). Si je travaille toute la
journée, je vais svn commettre deux fois par jour au moins (sauf
peut-être quand je chasse un bogue insidieux qui me prend plusieurs
jours).
Bien sûr, faire cent commit-s dans une journée serait quand m ême
excessif. Un truc très important, c'est d'avoir un message clair
associé à son commit (ce n'est pas facile). Dans un dévelo ppmeent
communautaire, c'est indispensable et fortement codifié (chaque entr ée
d'un ChangeLog de GCC correspond à un commit). Quand je bosse tout
seul, j'ai à tort la faiblesse de mettre des messages de commit trop
courts, et je le regrette plus tard.
Je confirme. Et d'ailleurs, c'est une règle de base dans les gros
projets collaboratifs (comme GCC). On commit des *petites*
modifications, souvent de quelques lignes ou douzaines de lignes.
Par exemple, sur GCC (versionné avec SVN), il y a 173221 commits dep uis
son origine (dans les années 1985?). Et les 5 derniers (obtenus par
svn log --limit 5) sont!
Comme tu peux le voir, les développeurs de gcc commettent des petits
patchs le plus souvent (quelques dizaines de lignes modifiées par co mmit).
Il peut arriver que la description du commit (c'est à dire l'entrà ©e dans
un ChangeLog) soit presque aussi grosse que le changement commis.
C'est aussi dû à la règle sociale de GCC: on ne peut y com mettre que du
code qui a été revu et approuvé par autrui.
Et même sur un développement où je suis tout seul, je comm ite plusieurs
fois par jour. Le temps entre deux commit, c'est le temps éléme ntaire
qu'on accepte de perdre. On a donc intérêt à ce qu'il ne s oit pas trop
long.
C'est aussi un avantage de GIT sur SVN: il sait faire des branches
facilement et il sait commiter rapidement.
En gros, je commite souvent après correction d'un seul bogue ou ajout
d'une seule fonction ou méthode (notamment quand elle est publique), ou
ajout de quelques douzaines de lignes au maximum. Je commite toujours
avant de partir (manger, ou chez moi). Si je travaille toute la
journée, je vais svn commettre deux fois par jour au moins (sauf
peut-être quand je chasse un bogue insidieux qui me prend plusieurs
jours).
Bien sûr, faire cent commit-s dans une journée serait quand m ême
excessif. Un truc très important, c'est d'avoir un message clair
associé à son commit (ce n'est pas facile). Dans un dévelo ppmeent
communautaire, c'est indispensable et fortement codifié (chaque entr ée
d'un ChangeLog de GCC correspond à un commit). Quand je bosse tout
seul, j'ai à tort la faiblesse de mettre des messages de commit trop
courts, et je le regrette plus tard.
Je confirme. Et d'ailleurs, c'est une règle de base dans les gros
projets collaboratifs (comme GCC). On commit des *petites*
modifications, souvent de quelques lignes ou douzaines de lignes.
Par exemple, sur GCC (versionné avec SVN), il y a 173221 commits dep uis
son origine (dans les années 1985?). Et les 5 derniers (obtenus par
svn log --limit 5) sont!
Comme tu peux le voir, les développeurs de gcc commettent des petits
patchs le plus souvent (quelques dizaines de lignes modifiées par co mmit).
Il peut arriver que la description du commit (c'est à dire l'entrà ©e dans
un ChangeLog) soit presque aussi grosse que le changement commis.
C'est aussi dû à la règle sociale de GCC: on ne peut y com mettre que du
code qui a été revu et approuvé par autrui.
Et même sur un développement où je suis tout seul, je comm ite plusieurs
fois par jour. Le temps entre deux commit, c'est le temps éléme ntaire
qu'on accepte de perdre. On a donc intérêt à ce qu'il ne s oit pas trop
long.
C'est aussi un avantage de GIT sur SVN: il sait faire des branches
facilement et il sait commiter rapidement.
En gros, je commite souvent après correction d'un seul bogue ou ajout
d'une seule fonction ou méthode (notamment quand elle est publique), ou
ajout de quelques douzaines de lignes au maximum. Je commite toujours
avant de partir (manger, ou chez moi). Si je travaille toute la
journée, je vais svn commettre deux fois par jour au moins (sauf
peut-être quand je chasse un bogue insidieux qui me prend plusieurs
jours).
Bien sûr, faire cent commit-s dans une journée serait quand m ême
excessif. Un truc très important, c'est d'avoir un message clair
associé à son commit (ce n'est pas facile). Dans un dévelo ppmeent
communautaire, c'est indispensable et fortement codifié (chaque entr ée
d'un ChangeLog de GCC correspond à un commit). Quand je bosse tout
seul, j'ai à tort la faiblesse de mettre des messages de commit trop
courts, et je le regrette plus tard.