Git pour les utilisateurs de Perforce

86

J'utilise Perforce depuis plusieurs années. J'aimerais passer à l'utilisation de git pour mon code personnel, mais tous les tutoriels git que j'ai vus supposent que vous êtes un contrôle de source complet n00b (ce qui les rend incroyablement fastidieux) ou que vous êtes habitué à svn (ce que je ne suis pas).

Je connais p4, et je comprends aussi l'idée derrière un système de contrôle de source distribué (donc je n'ai pas besoin d'un argumentaire de vente, merci). Ce que je voudrais, c'est une table de traduction de la commande p4 vers des commandes git équivalentes, ainsi que les commandes "ne peut pas vivre sans" qui n'ont pas d'équivalent p4.

Puisque je soupçonne que chaque utilisateur de p4 utilise un sous-ensemble différent de p4, voici quelques-unes des choses que je fais régulièrement dans p4 que j'aimerais pouvoir faire dans git qui ne sont pas immédiatement évidentes à partir des documents que j'ai consultés :

  1. créer plusieurs listes de modifications en attente dans un seul client. ( p4 change)
  2. modifier une liste de modifications en attente. (aussi p4 change)
  3. voir une liste de toutes mes listes de modifications en attente ( p4 changes -s pending)
  4. liste de tous les fichiers modifiés dans mon client ( p4 opened) ou dans une liste de modifications en attente ( p4 describe)
  5. voir un diff d'une liste de modifications en attente (j'utilise un script wrapper pour cela qui utilise p4 diffet p4 describe)
  6. pour un fichier donné, voir quelles listes de modifications soumises ont affecté quelles lignes ( p4 annotate)
  7. pour un fichier donné, voir une liste des descriptions des listes de modifications qui ont affecté le fichier ( p4 log)
  8. soumettre une liste de modifications en attente ( p4 submit -c)
  9. abandonner une liste de modifications en attente ( p4 revert)

Beaucoup d'entre eux tournent autour de "listes de modifications". "changelist" est la terminologie p4. Quel est le terme équivalent à git?

On dirait que les branches pourraient être ce que les utilisateurs de git utilisent à la place de ce que p4 appelle les listes de modifications. Un peu déroutant, car p4 a aussi quelque chose qui s'appelle une branche bien qu'ils ne semblent être que des concepts vaguement liés. (Bien que j'ai toujours pensé que le concept de branche de p4 était assez étrange, il est encore une fois différent du concept RCS classique d'une branche.)

Quoi qu'il en soit ... Je ne sais pas comment accomplir ce que je fais normalement dans les listes de modifications p4 avec les branches de git. Dans p4, je peux faire quelque chose comme ceci:

$ p4 edit a.txt
$ p4 change a.txt
Change 12345 created.

À ce stade, j'ai une liste de modifications qui contient a.txt. Je peux modifier la description et continuer à travailler sans soumettre la liste des modifications. De plus, s'il s'avère que j'ai besoin d'apporter des modifications à certains autres fichiers, comme par exemple un correctif dans une autre couche du code, je peux le faire dans le même client:

$ p4 edit z.txt
$ p4 change z.txt
Change 12346 created.

Maintenant, j'ai deux listes de modifications distinctes dans le même client. Je peux travailler sur ces derniers simultanément, et je n'ai rien à faire pour "basculer entre" eux. Quand vient le temps de m'engager, je peux les soumettre séparément:

$ p4 submit -c 12346  # this will submit the changes to z.txt
$ p4 submit -c 12345  # this will submit the changes to a.txt

Je ne peux pas comprendre comment répliquer cela dans git. D'après mes expériences, il ne semble pas que ce git addsoit associé à la branche actuelle. Pour autant que je sache, quand je git commitvais valider tous les fichiers que j'ai git addcréés, quelle que soit la branche dans laquelle je me trouvais à l'époque:

$ git init
Initialized empty Git repository in /home/laurence/git-playground/.git/
$ ls
a.txt  w.txt  z.txt
$ git add -A .
$ git commit
 Initial commit.
 3 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 a.txt
 create mode 100644 w.txt
 create mode 100644 z.txt
$ vi a.txt z.txt 
2 files to edit
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   a.txt
#   modified:   z.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git branch aardvark
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git add a.txt 
$ git checkout master
M   a.txt
M   z.txt
Switched to branch 'master'
$ git branch zebra
$ git checkout zebra
M   a.txt
M   z.txt
Switched to branch 'zebra'
$ git add z.txt 
$ git status
# On branch zebra
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt
#
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git status
# On branch aardvark
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt

Dans cet exemple, les branches aardvark et zebra semblent contenir exactement le même ensemble de modifications, et en fonction de la sortie de celles- git statusci, il semble que faire un commit dans l'une ou l'autre aura le même effet. Est-ce que je fais quelque chose de mal?

git perforce Laurence Gonsalves
la source
2
Vous pouvez simplement utiliser perforce pour votre code personnel en supposant que les 5 clients gratuits suffisent.
Logan Capaldo
3
C'est ce que j'avais fait, mais j'aimerais passer à quelque chose qui est open-source et également utilisé par des projets open-source. J'ai envisagé à la fois git et Mercurial. Je me suis penché vers git parce qu'il semble avoir plus d'élan.
Laurence Gonsalves
1
Vous feriez mieux d'apprendre Git à partir de zéro. Le workflow prescrit par Git est très différent du workflow prescrit par Perforce. Les flux de travail traduits seront gênants et essayer d'assimiler les fonctionnalités nuira à votre compréhension. Heureusement, la communauté Git offre une richesse de documentation pour les débutants, par exemple. git-scm.com/book
Colonel Panic
1
@ColonelPanic Je peux comprendre votre point de vue, mais le problème avec une telle documentation est qu'elle perd du temps à expliquer des choses de base que chaque utilisateur de Perforce connaîtrait déjà. Lire une telle documentation est tout aussi ennuyeux que d'essayer de lire un tutoriel sur un autre langage de programmation qui passe un chapitre à expliquer ce que sont les variables.
Laurence Gonsalves
@ColonelPanic Cela dit, j'ai lu une autre documentation git, y compris Git From the Bottom Up et Git for Computer Scientists, qui étaient en fait très utiles. J'utilise Git depuis quelques années maintenant (notez quand cette question a été posée à l'origine), et je pense que les principaux problèmes avec l'apprentissage de git ne sont pas le manque de documentation, mais une mauvaise nomenclature, une incohérence interne, des commandes très surchargées, et certains des pièces non finies qui ne sont pas prêtes pour une utilisation réelle. J'aurais aimé que quelqu'un aille nettoyer tous les déchets, mais cela ennuierait ceux qui s'y sont habitués.
Laurence Gonsalves

Réponses:

72

Je n'ai pas beaucoup utilisé forcément, donc ce n'est peut-être pas exactement une traduction 1: 1. Là encore, les systèmes de contrôle de source distribués comme git et mercurial ont de toute façon un flux de travail différent, donc il n'y a vraiment pas (et il ne devrait pas y avoir) de traduction 1: 1. Quoi qu'il en soit, voici:

  • Créez plusieurs listes de modifications en attente -> Utilisez plutôt des branches. Dans git, les branches sont légères et rapides, prennent moins d'une seconde à créer et généralement moins de deux secondes à fusionner. N'ayez pas peur des branches et rebase souvent.

    git branch new-branch-name
git checkout new-branch-name

    Ou faites tout cela en une seule ligne:

    git checkout -b new-branch-name

  • Voir une liste de toutes les listes de modifications en attente -> Étant donné que l'équivalent de plusieurs listes de modifications en attente est plusieurs branches, affichez simplement les branches:

    git branch

    Si vous souhaitez également afficher les branches distantes:

    git branch -a

    Il est recommandé de supprimer immédiatement une branche après une fusion réussie afin de ne pas avoir à garder une trace des branches en attente de fusion et de celles qui ont déjà été fusionnées.

  • Liste tous les fichiers modifiés -> Pour une seule "liste de modifications" en attente dans une branche spécifique, git a un concept d'index ou de cache. Pour valider une modification, vous devez d'abord ajouter des fichiers à cet index. Cela vous permet de sélectionner manuellement le groupe de fichiers représentant un seul changement ou d'ignorer les fichiers non pertinents. Pour voir l'état des fichiers ajoutés ou non à cet index, faites simplement:

    git status

  • Voir un diff d'une liste de modifications en attente -> Il y a deux parties à cela. Tout d'abord pour voir une différence entre le répertoire de travail et l'index:

    git diff

    Mais si vous voulez connaître la différence entre ce que vous tapez maintenant et le dernier commit, vous demandez vraiment une différence entre le répertoire de travail + index et la HEAD:

    git diff HEAD

  • Pour un fichier donné, voir quelles listes de modifications soumises ont affecté quelles lignes -> C'est facile:

    git blame filename

    ou encore mieux, si vous êtes dans un environnement fenêtré:

    git gui blame filename

    Git gui prend plus de temps pour analyser le fichier (il a été écrit en tcl au lieu de C) mais il a beaucoup de fonctionnalités intéressantes, y compris la possibilité de "voyager dans le temps" dans le passé en cliquant sur un ID de validation. Je souhaite seulement qu'ils implémentent une fonctionnalité pour "voyager dans le temps" dans le futur afin que je puisse découvrir comment un bug donné sera finalement résolu ;-)

  • Pour un fichier donné, voir une liste des descriptions des listes de modifications qui ont affecté le fichier -> aussi facile:

    git log filename

    Mais git log est un outil beaucoup plus puissant que cela. En fait, la plupart de mes scripts personnels se superposent à git log pour lire le référentiel. Lisez la page de manuel.

  • Soumettez une liste de modifications en attente -> Aussi facile:

    git commit

Voir ma réponse à une question précédente pour voir mon workflow git typique: Apprendre Git. Besoin de savoir si je suis sur la bonne voie

Si vous suivez le flux de travail que j'ai décrit, vous constaterez que des outils comme gitk sont beaucoup plus précieux car ils vous permettent de voir clairement les groupes de modifications.

Réponse supplémentaire:

Git est très flexible et il existe plusieurs façons de faire ce que vous décrivez. La chose à retenir est de toujours démarrer une nouvelle branche pour chaque fonctionnalité sur laquelle vous travaillez. Cela signifie que la branche master n'est pas touchée, donc vous pouvez toujours y revenir pour corriger les bogues. Travailler dans git devrait presque toujours commencer par:

git checkout -b new-feature-a

Vous pouvez maintenant éditer le fichier a.txt. Pour travailler simultanément sur une autre fonctionnalité, procédez comme suit:

git checkout master
git checkout -b new-feature-z

Vous pouvez maintenant éditer le fichier z.txt. Pour revenir à a.txt:

git checkout new-feature-a

Mais attendez, il y a des changements dans new-feature-z et git ne vous permettra pas de changer de branche. À ce stade, vous avez deux choix. Le premier est le plus simple, validez toutes les modifications dans la branche actuelle:

git add .
git commit
git checkout new-feature-a

C'est ce que je recommande. Mais si vous n'êtes vraiment pas prêt à valider le code, vous pouvez le cacher temporairement:

git stash

Vous pouvez maintenant passer à la branche new-feature-a. Pour revenir au code sur lequel vous travailliez, ouvrez simplement la cachette:

git checkout new-feature-z
git stash pop

Lorsque tout est terminé, fusionnez toutes les modifications apportées au master:

git merge --no-ff new-feature-a
git merge --no-ff new-feature-z

Parce que les fusions sont si rapides et faciles (faciles parce que les conflits sont si rares et la résolution des conflits, quand cela se produit, pas trop difficile), nous utilisons des branches dans git pour tout.

Voici un autre exemple d'utilisation courante de branches dans git que vous ne voyez pas dans d'autres outils de contrôle de source (sauf peut-être mercurial):

Besoin de continuer à modifier vos fichiers de configuration pour refléter votre environnement de développement? Ensuite, utilisez une branche:

git checkout -b dev-config

Maintenant, modifiez vos fichiers de configuration dans votre éditeur préféré puis validez les modifications:

git add .
git commit

Désormais, chaque nouvelle branche peut démarrer à partir de la branche dev-config au lieu de master:

git checkout dev-config
git checkout -b new-feature-branch

Une fois que vous avez terminé, supprimez les modifications dans dev-config de new-feature-branch en utilisant le rebase interactif:

git rebase -i master

Supprimez les commits que vous ne souhaitez pas, puis enregistrez-les. Vous avez maintenant une branche propre sans modifications de configuration personnalisées. Il est temps de revenir au maître:

git checkout master
git merge --no-ff new-feature-branch
# because master have changed, it's a good idea to rebase dev-config:
git checkout dev-config
git rebase master

Il convient de noter que la suppression des modifications avec git rebase -ifonctionne même lorsque toutes les modifications se produisent dans le même fichier. Git se souvient des modifications, pas du contenu du fichier *.

* note: en fait, techniquement pas tout à fait vrai, mais en tant qu'utilisateur, c'est ce que l'on ressent

Plus de réponse supplémentaire:

Ainsi, d'après vos commentaires, il semble que vous souhaitiez que deux branches existent simultanément afin que vous puissiez tester le fonctionnement du code combiné. Eh bien, c'est un bon moyen d'illustrer la puissance et la flexibilité des branches.

Tout d'abord, un mot sur l'implication de la branche bon marché et de l'historique modifiable sur votre flux de travail. Quand j'utilisais CVS et SVN, j'étais toujours un peu réticent à m'engager. C'est parce que la validation de code instable serait inévitablement f ** k le code de travail des autres. Mais avec git j'ai perdu cette peur. C'est parce que dans git, les autres personnes ne recevront pas mes modifications tant que je ne les fusionnerai pas avec master. Alors maintenant, je me retrouve à commettre du code toutes les 5 lignes que j'écris. Vous n'avez pas besoin d'une prévoyance parfaite pour vous engager. Vous avez juste besoin de changer votre état d'esprit: commit-to-branch == add-to-changeset, merge-to-master == commit-changeset.

Alors, revenons aux exemples. Voici comment je le ferais. Supposons que vous ayez une branche new-feature-zet que vous souhaitiez la tester new-feature-a. Je créerais juste une nouvelle branche pour la tester:

# assume we are currently in branch new-feature-z
# branch off this branch for testing
git checkout -b feature-z-and-feature-a
# now temporarily merge new-feature-a
git merge --no-ff new-feature-a

Vous pouvez maintenant tester. Si vous avez besoin de modifier quelque chose pour que feature-z fonctionne avec feature-a, faites-le. Si tel est le cas, vous pouvez fusionner les modifications dans la branche appropriée. Permet git rebase -ide supprimer les modifications non pertinentes de la fusion.

Vous pouvez également utiliser git rebase pour modifier temporairement la base de new-feature-z pour qu'elle pointe vers new-feature-a:

# assume we are currently in branch new-feature-z
git rebase new-feature-a

Maintenant, l'historique des branches est modifié de sorte que new-feature-z soit basé sur new-feature-a au lieu de master. Vous pouvez maintenant tester. Tout changement effectué dans cette branche appartiendra à la branche new-feature-z. Si vous avez besoin de modifier une nouvelle fonctionnalité, revenez-y simplement et le rebase pour obtenir les nouvelles modifications:

git checkout new-feature-a
# edit code, add, commit etc..
git checkout new-feature-z
git rebase new-feature-a
# now new-feature-z will contain new changes from new-feature-a

Lorsque vous avez terminé, rebasez simplement vers master pour supprimer les modifications de new-feature-a:

# assume we are currently in branch new-feature-z
git rebase master

N'ayez pas peur de créer une nouvelle succursale. N'ayez pas peur de démarrer une succursale jetable. N'ayez pas peur de jeter les branches. Et puisque merge == submit et commit == add-to-changeset n'ayez pas peur de vous engager souvent. N'oubliez pas que la validation est l'outil d'annulation ultime du développeur.

Oh, et autre chose, dans git, les branches supprimées existent toujours dans votre référentiel. Donc, si vous avez accidentellement supprimé quelque chose que vous réalisez plus tard comme utile après tout, vous pouvez toujours le récupérer en recherchant dans l'historique. Alors n'ayez pas peur de jeter les branches.

dormeur
la source
1
Chaque branche a-t-elle son propre "index", ou y a-t-il un seul index partagé entre les branches? Mon expérience semble suggérer ce dernier, mais vous dites "une branche spécifique git a un concept d'index ou de cache" qui suggère le premier.
Laurence Gonsalves
4
C'est un outil différent. Vous avez besoin d'un flux de travail différent et avec cela un état d'esprit et une habitude différents. Aucun git ne fonctionne comme vous le décrivez. Ce sont des branches et rien d'autre. Mais il existe des outils de manipulation de branche très puissants. Je vous suggère de vous considérer comme un débutant qui ne sait rien du contrôle de code source et de lire les tutoriels de base. Considérez votre état d'esprit actuel "bad habbit" contre lequel vous devez être rééduqué dans git-land. Désolé ..
slebetman
1
Alors, que faites-vous dans git lorsque vous avez deux choses sur lesquelles vous voulez travailler simultanément (et au même endroit, afin que vous puissiez tester les modifications non validées les unes par rapport aux autres), mais que vous voulez les valider séparément? De plus, comment pouvez-vous modifier un message de validation avant d'effectuer une validation? Je peux accepter que le flux de travail soit différent, mais vous n'avez pas dit quel est le flux de travail équivalent à git. Dire que ce sont de mauvaises habitudes ressemble beaucoup à essayer de faire passer un bogue pour une fonctionnalité.
Laurence Gonsalves
2
Lisez ma réponse mise à jour. Vous pensez toujours en termes de changements non engagés alors que vous devriez penser aux branches non fusionnées.
slebetman
2
Réponse très complète. À quel moment cela doit-il être wikifié?
Tim Clemons
1

Je n'ai pas assez d'expérience p4 pour produire une feuille de triche réelle, mais il y a au moins quelques similitudes sur lesquelles se rabattre. Un "changeset" p4 est un git "commit".

Les modifications apportées à votre espace de travail local sont ajoutées à «l'index» avec git add, et l'index est ensuite validé avec git commit. L'index est donc votre liste de modifications en attente, à toutes fins utiles.

Vous regardez les modifications avec git diffet git status, où git diffaffiche généralement les modifications entre l'espace de travail et l'index, mais git diff --cachedaffiche les modifications entre l'index et le référentiel (= votre liste de modifications en attente).

Pour plus d'informations, je recommande http://progit.org/book/ . Puisque vous connaissez le contrôle de version en général, vous pouvez probablement en parcourir beaucoup et en extraire les informations spécifiques à git ...

Jakob Borg
la source
1
Je ne suis pas d'accord avec le fait qu '"un changeset p4 est un commit git"; ce sont les équivalents les plus proches, c'est vrai, mais un changeset p4 est beaucoup plus proche d'un ensemble de commits git. Un changeset p4 représente une fonctionnalité, tandis qu'une branche git représente une fonctionnalité.
RJFalconer
@RJFalconer Erm. Une "branche" est une branche dans Perforce aussi, non? Et un "changeset" est une collection atomique de changements à un ou plusieurs fichiers, un peu comme un commit? Sinon, quel est, selon vous, l'équivalent p4 de commit?
Jakob Borg
Je dirais que p4 n'a pas d'équivalent, simplement parce que le degré d'atomicité n'est pas le même; dans git, je peux faire plusieurs changements dans un fichier donné puis les valider dans différents commits (git add -p), séparant ainsi le refactoring / nettoyage dans l'historique de la fonctionnalité / correction de bogue. Si je devais faire cela en p4, je devrais développer les deux séparément. Même dans ce cas, mes commits peuvent ne pas être continus car d'autres développeurs peuvent soumettre entre eux (sauf si je branche privée, ce qui implique une duplication souvent peu pratique sur le disque).
RJFalconer
Avertissement: je n'utilise p4 que depuis quelques mois et il est fort possible qu'il y ait une fonctionnalité qui accomplit cela que je n'ai tout simplement pas encore rencontrée.
RJFalconer
Les listes de modifications p4 et les branches p4 sont logiquement les mêmes que les commits git et les branches git. p4 shelve est l'équivalent de git stash. Là où ils diffèrent, c'est dans l'implémentation (c.-à-d. Distribué ou client-serveur) et cette différence se traduit par l'équivalent p4 de git checkout impliquant plusieurs étapes et un temps considérable. La surcharge est telle que plusieurs branches sont généralement conservées localement sur le disque au lieu de faire l'équivalent de git checkout. Les étagères p4 sont stockées sur le serveur plutôt dans le dépôt local.
Josh Heitzman
1

Je souffre comme vous de l'absence du concept de "changelist" qui n'est pas exactement le même que celui des branches git.

J'écrirais un petit script qui créera un fichier de liste de modifications avec la liste des fichiers de cette liste de modifications.

Une autre commande pour soumettre juste une certaine liste de modifications en appelant simplement git commit -a @ change_list_contents.txt puis "git commit"

J'espère que ça aide, Elias

Elias Bachaalany
la source
Oui, j'ai en fait envisagé de faire quelque chose comme ça, même si au moment où j'ai posé cette question j'étais nouveau dans git et donc je voulais connaître la solution "native". Maintenant, je trouve que la principale chose qui me manque est la possibilité de travailler sur un message de validation sans réellement s'engager. Ainsi pourrait être résolu en ayant un fichier pour contenir le "message de validation en attente", et peut-être un peu de magie pour le lire automatiquement lors de l'écriture d'un message de validation.
Laurence Gonsalves
@LaurenceGonsalves, le workflow que j'utilise est de commettre des messages de commit imparfaits (ou même juste "WIP") pendant que je suis concentré sur le travail, puis de les modifier plus tard lors de mon rebase. Comme les commits sont purement locaux, ils n'ont pas besoin d'être définitifs tant que vous n'aurez pas rendu votre branche disponible (en la poussant sur votre télécommande ou similaire).
RJFalconer
1

Il existe une alternative plus légère dans git qui pourrait faire partie de votre flux de travail; en utilisant la zone de préparation de git.

Je fais souvent des changements puis je les soumets en plusieurs commits (par exemple, ajouter des déclarations de débogage, refactoriser, corriger un bogue). Plutôt que de configurer vos listes de modifications perforce, puis d'apporter des modifications, puis de soumettre, vous pouvez simplement effectuer vos modifications, puis choisir comment les soumettre (éventuellement en utilisant la zone de préparation de git).

Vous pouvez valider des fichiers particuliers depuis la ligne de commande avec:

git commit a.txt
git commit z.txt

Ou préparez explicitement les fichiers en premier:

git add a.txt
git commit
git add z.txt
git commit

git gui vous permettra de sélectionner des lignes ou des morceaux dans les fichiers pour créer un commit dans la zone de préparation. Ceci est très utile si vous avez des modifications dans un fichier que vous souhaitez inclure dans différents commits. Être passé de git à forcé et c'est une chose qui me manque vraiment.

Il y a une petite mise en garde à garder à l'esprit avec ce flux de travail. Si vous apportez des modifications A et B à un fichier, testez le fichier, puis validez A, vous n'avez pas testé cette validation (indépendamment de B).

Russell Gallop
la source
Il est certainement vrai que git vous permet de faire des commits encore plus fins que perforce (c'est-à-dire des lignes et des morceaux). Ce qui me manque (toujours) de perforce, c'est la possibilité de garder une trace de la description du changement (alias message de validation) pour ce sur quoi je travaille actuellement. Par exemple, lorsque je vais corriger le bogue # 12345, je créerai une liste de modifications indiquant que je faisais cela (mais je ne la soumettrai pas). Ensuite, au fur et à mesure que j'y travaillais, je mettrais à jour la description du changement pour indiquer ce que j'avais fait. Enfin, quand j'aurai terminé, je commettrai la liste des modifications.
Laurence Gonsalves
Dans git, il semble que l'équivalent approximatif est de valider ces petits bits (souvent non fonctionnels) dans une branche de développement, puis une fois que tout est ok pour fusionner les changements. Cela me semble encore beaucoup plus fastidieux et maladroit. De plus, je ne me suis toujours pas vraiment habitué à l'idée de commettre du code qui ne se compile même pas.
Laurence Gonsalves
@LaurenceGonsalves Curieux de savoir si vous vous y êtes habitué entre-temps. J'arrive à Perforce depuis Git et je manque de pouvoir m'engager toutes les 15 minutes, puis pousser quand je suis prêt.
damian
0

Cela ne répond pas spécifiquement à votre question, mais je ne sais pas si vous savez qu'une version 2 utilisateurs, 5 espaces de travail de perforce peut être téléchargée et utilisée gratuitement à partir du site Web de perforce .

De cette façon, vous pouvez utiliser forforce à la maison pour vos projets personnels si vous le souhaitez. Le seul inconvénient, ce sont les 5 espaces de travail qui peuvent être un peu limitatifs, mais c'est assez incroyable d'avoir forcément disponible pour un usage domestique.

Toby Allen
la source
2
C'est ce que j'avais fait, mais j'aimerais passer à quelque chose qui est open-source et également utilisé par des projets open-source.
Laurence Gonsalves
0

Ayant utilisé à la fois Perforce et git assez largement, je ne peux voir qu'une seule façon de me rapprocher des listes de modifications Perforce avec git.

La première chose à comprendre est que pour implémenter correctement cette fonctionnalité dans git de manière à ce que ce ne soit pas un kluge complet, par exemple essayer de la faire passer dans les branches, il faudrait le changement suivant: git nécessiterait plusieurs zones de préparation pour une seule branche .

Les listes de modifications Perforce permettent un flux de travail qui n'a tout simplement pas d'équivalent dans git. Considérez le flux de travail suivant:

Check out a branch
Modify file A and add it to changelist 1
Modify file B and add it to changelist 2

Si vous essayez de faire cela en utilisant des branches dans git, vous vous retrouverez avec deux branches, dont l'une a les modifications du fichier A, l'autre les modifications du fichier B, mais aucun endroit où vous pouvez voir les modifications apportées aux deux fichiers Aet Bà le même temps.

Le plus proche approximation que je peux voir est d'utiliser git add . -p, puis utilisez les 'a'et 'd'sous-commandes pour sélectionner ou rejeter des fichiers entiers. Cependant, ce n'est pas tout à fait la même chose, et la différence ici provient d'une disparité fondamentale dans le mode de fonctionnement général des deux systèmes.

Git (et subversion, non pas que cela compte pour cette discussion) permet à un fichier d'être modifié sans en parler à personne à l'avance. Vous changez simplement un fichier, puis laissez git trier le tout lorsque vous validez les modifications. Perforce vous oblige à extraire activement un fichier avant que les modifications ne soient autorisées, et c'est pour cette raison que des listes de modifications doivent exister. Par essence, Perforce vous oblige à ajouter un fichier à l'index avant de le modifier. D'où la nécessité de plusieurs listes de modifications dans Perforce, et aussi la raison pour laquelle git n'a pas d'équivalent. Il n'en a tout simplement pas besoin.

dgnuff
la source
0

Avec Git 2.27 (Q2 2020), " git p4" a appris quatre nouveaux hooks et aussi " --no-verify" une option pour les contourner (et le p4-pre-submithook " " existant ).

Voir commit 1ec4a0a , commit 38ecf75 , commit cd1e0dc (14 février 2020) et commit 4935c45 , commit aa8b766 , commit 9f59ca4 , commit 6b602a2 (11 février 2020) par Ben Keene ( seraphire) .
(Fusionné par Junio ​​C Hamano - gitster- dans commit 5f2ec21 , 22 avril 2020)

git-p4: ajouter des hooks de soumission p4

Signé par: Ben Keene

La commande git " commit" prend en charge un certain nombre de hooks qui prennent en charge la modification du comportement de la commande commit.

Le git-p4.pyprogramme n'a qu'un seul hook existant, " p4-pre-submit".

Cette commande intervient au début du processus.

Il n'y a pas de hooks dans le flux de processus pour modifier le texte de la liste de modifications P4 par programme.

Ajoute 3 nouveaux hooks git-p4.pyà l'option d'envoi.

Les nouveaux crochets sont:

  • p4-prepare-changelist- Exécutez ce hook après la création du fichier de liste de modifications.
    Le hook sera exécuté même si l' --prepare-p4-onlyoption est définie.
    Ce hook ignore l' --no-verifyoption conformément au comportement existant de git commit.

  • p4-changelist- Exécutez ce hook après que l'utilisateur a modifié la liste des modifications.
    N'exécutez pas ce hook si l'utilisateur a sélectionné l' --prepare-p4-onlyoption.
    Ce crochet respectera le --no-verify, suivant les conventions de git commit.

  • p4-post-changelist- Exécutez ce hook une fois le processus de soumission P4 terminé avec succès.
    Ce hook ne prend aucun paramètre et est exécuté quelle que soit l' --no-verifyoption.

Sa valeur de retour ne sera pas vérifiée.

Les appels vers les nouveaux crochets: p4-prepare-changelist, p4-changelistet p4-post-changelistdoivent tous être appelés à l' intérieur du bloc try-finally.

Avant Git 2.28 (Q3 2020), l' --prepare-p4-onlyoption " " est censée s'arrêter après avoir relu un ensemble de modifications, mais a continué (par erreur?)

Voir commit 2dfdd70 (12 mai 2020) par Ben Keene ( seraphire) .
(Fusionné par Junio ​​C Hamano - gitster- dans commit 7a8fec9 , 02 juin 2020)

git-p4.py: correction d'une --prepare-p4-onlyerreur avec plusieurs commits

Signé par: Ben Keene

Lors de l'utilisation git p4 submitavec l' --prepare-p4-onlyoption, le programme doit préparer une seule liste de modifications p4 et informer l'utilisateur que d'autres validations sont en attente, puis arrêter le traitement.

Un bogue a été introduit par la p4-changelistfonction hook qui oblige le programme à continuer d'essayer de traiter toutes les listes de modifications en attente en même temps.

La fonction applyCommitretourne Truelorsque l'application de la validation a réussi et le programme doit continuer.
Cependant, lorsque l'indicateur facultatif --prepare-p4-onlyest défini, le programme doit s'arrêter après la première application.

Modifiez la logique de la méthode d'exécution pour P4Submit pour vérifier l'indicateur une --prepare-p4-onlyfois la applyCommitméthode terminée .

Si plus d'un commit est en attente de soumission à P4, la méthode préparera correctement la liste de modifications P4, mais elle quittera toujours l'application avec un exitcode de 1.

La documentation actuelle ne définit pas ce que doit être le code de sortie dans cette condition.

VonC
la source