2010-09-30 71 views
15

Je n'aime vraiment pas la zone de mise en scène git, cela rend ma vie inutilement confuse.Désactiver la zone de mise en scène git

Est-il possible de le désactiver pour que tous les fichiers édités et nouveaux soient dans un seul contexte? Alors que git diff montre le diff entre le dépôt et mon répertoire de travail (et je n'ai pas besoin de taper aussi git diff --cached) et que git ci vérifie dans toute ma copie de travail (pas seulement la partie qui est mise en scène). Si ce n'est pas le cas, des alternatives (comme la configuration de cofigurations) pour que je n'aie pas de mise en scène seraient également très bien.

Je n'ai pas la possibilité de passer à un autre DVCS et je ne veux pas apprendre à aimer la zone de transit. S'il vous plaît ne pas poster de suggérer ces :(

Merci, -Shawn

PS: J'ai demandé cela sur superuser.com, https://superuser.com/questions/192022/disable-git-staging-area, mais ce forum semble avoir beaucoup moins affiché (seulement 118 git marqués par rapport à 4448 ici)

+0

Je ne supprimerais jamais la mise en scène même si possible, mais je vous ai voté juste pour voir si c'est possible. – matpie

+4

Être développeur, c'est apprendre. Je ne peux même pas imaginer pourquoi vous voudriez ignorer vos outils et ne pas apprendre à utiliser leurs plus grandes forces. Êtes-vous également opposé à l'apprentissage de nouvelles API ou de nouveaux modèles de conception? :/ – Daenyth

+7

@Daenyth: Je n'ai aucun problème avec l'apprentissage de nouveaux outils. Je comprends que cela * pourrait * être une option utile pour certaines personnes à certains moments. Je suis sûr que dans ma situation ce n'est pas utile. Je pense qu'il est idiot que git vous oblige à utiliser certaines technologies (comme la zone de transit) plutôt que de vous permettre simplement de les utiliser. Parfois, vous avez besoin d'un tournevis et parfois d'un marteau, mais je serais énervé si mon tournevis avait un marteau intégré que je devais naviguer juste pour que je puisse dévisser ma poignée de porte. – sligocki

Répondre

1

Vous pouvez simplement utiliser git commit -a pour commettre tous modifiés/fichiers supprimés. Vous n'avez pas encore ajouter des fichiers trassez pensé manuellement.

Je suis venu de Subversion et a été confondu par la zone de mise en scène dans un premier temps aussi. Mais vous le trouverez très utile. les modifications que vous avez testées, mais qui apportent plus de modifications à votre build, vous permettent de revenir aux modifications par étapes.

+1

Oui, j'utilise toujours git ci -a ces jours-ci, mais (malheureusement) je ne peux pas mettre ci = commit -a dans mon rc parce que je ne peux pas commettre un seul fichier (via git ci foo) parce qu'il se plaint de a et liste de fichiers explicite. – sligocki

1

La zone de transit est l'un des plus grands atouts de Git et représente vraiment la différence par rapport à n'importe quel autre DVCS.

Vous pouvez utiliser

git commit -a 

pour ajouter automatiquement les fichiers modifiés. Pour les fichiers non suivis, vous êtes seul. Pratique git add . && git commit.

Si vous ne l'aimez pas, utilisez un autre VCS. Obligé d'utiliser un dépôt git? Voir certains des plugins disponibles qui sont compatibles, tels que hg-git. Personnellement, j'apprendrais à jouer sur les forces de git au lieu de le combattre. Imaginez que vous êtes au milieu d'une grosse branche en désordre, mais que vous avez besoin de quelques modifications sélectives pour la production. Boom, git add [files] puis validez et appuyez. Retournez au travail sans rien changer d'autre. Il y a d'innombrables autres exemples, mais c'est peut-être le plus facile à comprendre.

+1

Pas une option pour en utiliser une autre. Je suis coincé avec cet outil. – sligocki

+0

@sligocki: Vous pouvez utiliser plusieurs options à la place de git pour émuler un dépôt git. Voir [hg-git] (http://hg-git.github.com/). –

+3

non, je ne peux pas. Je suis vraiment fatigué des gens qui disent ça! J'utilise des outils qui sont construits sur git, je n'ai pas l'option d'utiliser un autre DVCS ou ces outils ne fonctionneront pas et l'avantage d'utiliser un DVCS en premier lieu serait parti. – sligocki

6

Non. Vous apprenez à l'aimer.

Sur une note plus sérieuse, git add -A; git commit est probablement votre ami. De cette façon, vous évitez la plupart des interactions avec (et les avantages de) la zone de transit.

git add -A est plus puissant que l'habituel git commit -a. Il va trouver de nouveaux fichiers ainsi que mettre en scène le contenu modifié et supprimer les fichiers qui ne sont plus dans l'arbre de travail.

+0

Pourquoi devrions-nous apprendre à l'aimer s'il est possible d'automatiser toutes ces procédures de mise en scène manuelle? –

+0

@VitaliPom Parce que c'est vraiment utile, bien sûr. –

+2

Purement une question d'opinion que vous "apprendre à l'aimer". La zone de transit entrave simplement mon utilisation normale. –

4

Les alias sont vos amis.

Par exemple, vous pouvez créer une commande diff qui fait ce que vous voulez avec frappe minimale: dans votre .gitconfig mis

[alias] 
     di = diff HEAD 
     co = commit -a 

Vous pouvez alors faire simplement git di et vous obtenez votre propre diff, ou git co et obtenir votre propre commande de validation personnelle.

+1

mais alors git di ne me montrera pas ce qui est dans mon répertoire de travail, je veux git diff pour me montrer le changement qui sera commis quand je commet -a. – sligocki

+1

De même, je ne peux pas mettre co = commit -a dans mon rc parce que je n'ai pas pu commettre un seul fichier (via git ci foo) car il se plaint d'un conflit entre -a et la liste de fichiers explicite. – sligocki

+0

@sligocki: J'ai changé l'alias pour que 'git di' vous donne ce que vous avez indiqué dans votre premier commentaire. En ce qui concerne votre 2ème commentaire: vous pouvez valider un seul fichier avec l'habituel 'git commit foo'. – EOL

0

et je ne veux pas apprendre à aimer la zone de transit. S'il vous plaît ne pas poster de suggérer ces :(

Comme tous les autres. Je vais vous suggérer d'apprendre à aimer la zone de mise en scène. Il est vraiment utile, même si 90% du temps, vous Si vous ne le trouvez pas utile, je pense que vous pensez à commettre une erreur, vous pensez toujours en termes de fichiers uniques ou de tout à la fois. est par caractéristique/fix et les fonctions/corrections sont souvent réparties sur plus d'un fichier.Vous devez regrouper les changements liés dans un seul commit et parfois ce groupe de changements n'inclut pas tous les changements en cours. utile Je sais que ce n'est pas ce que vous voulez entendre, mais vraiment, le moment où vous arrêtez de combattre l'outil et apprenez à vivre avec est le moment où il cesse d'être "douloureux" pour utiliser l'outil.

+0

Merci slebetman, je vois pourquoi la zone de transit pourrait être utile. Ce n'est pas vraiment douloureux pour moi en ce moment, ça rend les choses plus compliquées, de temps en temps je vais lancer git diff et être confus pourquoi certains des fichiers ne sont pas là. Dans ma situation, je suis en train de pousser de git dans un repo perforce, donc les révisions git sont uniquement pour moi et peut donc être beaucoup plus brut. Donc, je ne me vois pas à vouloir créer l'historique des révisions, il suffit de l'utiliser pour revenir à un état de travail antérieur ou essayer de nouveaux chemins de développement. – sligocki

+0

Plutôt que de faire cela, essayez à la place de faire vos changements, puis utilisez git diff seulement pour voir "Ok, que dois-je encore ajouter au commit actuel". Si vous voyez que la différence est ce que vous voulez ajouter, ajoutez-la. Sinon, supprimez-le ou ignorez-le. Continuez à travailler jusqu'à ce que git diff ne montre aucun changement, alors vous serez prêt à valider vos modifications. – Arafangion