'git pull origin' - Fehlermeldung was tun?

[vrms]

ich habe hier eine lokale installation von odoo, das per git clone (github.com/OCA/OCB) installiert ist

updates mache ich per

Code: Alles auswählen

git pull origin 8.0

innerhalb meines lokalen odoo repositories gibt es noch andere git repositories, die Module fuer odoo enthalten [die nicht im basis paket enthalten sind]. Diese subfolder habe ich in meinem lokalen .gitignore aufgelistet. Dies ist ja eigentlich gu und richtig aber nun bekomme ich (logischerweise wie ich zugeben muss) eine Fehlermeldung beim pullen meines 'Muttergits'

Your local changes of the following file would be overwritten by merge:
.gitignore
Please, commit your changes or stash them before you can merge

Mir scheint, das eigentlich alles andere (ausser dem gemeldeten .gitignore) gemerged ist, denn ein Bug, den ich durhc diesen pull beseitigen wollte scheint tatsaechlich nicht mehr da zu sein. Nun Frage ich mich, was ich nun am besten jetzt konkret (also Schritt duer Schritt, denn ich bin ein ziemllicher Laie in git) tue. Den Fehler ignorieren vielleicht? oder tatsaechlich ein stash? Oder muss ich ggf. .gitignore ebenfalls zum .gitignore zufuegen?

zum Hintergrund: ich bin nicht an der Entwicklung von odoo beteiligt, sondern nutze git nur im meine Installation aktuall zu halten. Also wird niemals etas von meinem lokalen repo in Richtung 'remote' gehen

[novalix]

Hi,

wahrscheinlich müsstest Du die Änderungen in .gitignore committen oder zurück nehmen, um die Fehler- bzw. Warnmeldung zu vermeiden.
Vielleicht wäre es eine gute Idee einfach eine eigene Branch des Repos zu erstellen.

Code: Alles auswählen

man git-branch

Alle Änderungen die Du lokal vornimmst erledigst Du innerhalb dieser Branch.

Code: Alles auswählen

git checkout -b DeineBranch

Weiteres steht auch hier in der manpage (wie immer bei git werden die Befehle auseinander geschrieben, beim Aufruf der manuals jedoch mit Bindestrich verbunden).
In Deiner Branch kannst Du committen bis die Tastatur qualmt, Du kannst die gesamte Software umschreiben. Das interessiert master nicht die Bohne.



Edit: Typo

[Cae]

git status wird dir vermutlich mitteilen, dass die .gitignore getrackt ist und Modifikationen enthaelt. Die musst du erst committen, bevor du dann pullen kannst, was moeglicherweise einen merge-Konflikt hervorruft, wenn der Upstream ebenfalls eine .gitignore shippt. Den kannst du anschliessend loesen und ggf. gleich nochmal committen. Oder halt direkt deine Version drueberfahren, falls das gewuenscht ist (git pull -s ours).

Im Uebrigen kann man per git submodule auch gestapelte Repositories sauber voneinander trennen (separater Upstream, Tree, etc.).

Gruss Cae

[vrms]

Vielleicht wäre es eine gute Idee einfach eine eigene Branch des Repos zu erstellen. ...
Alle Änderungen die Du lokal vornimmst erledigst Du innerhalb dieser Branch.

ich bin aktuell im branch 8.0 meines remotes. Mal angenommen ich mache mit

Code: Alles auswählen

git branch 8.0 [mein branch]

meinen eigenen lokalen branch (der remote nicht existiert und auch nicht existieren wird weil ich gar keinen Schreibzugriff auf das remote habe [und diesen auch nicht brache/will])
wie kann ich dann [mein branch] naechstes Mal mit den Daten von remote origin 8.0 versorgen?

Code: Alles auswählen

git checkout [mein branch]
git pull origin 8.0

etwa? (also meine logik hier waere: im moment in dem ich git sage von branch 8.0 zu pullen sitze in [mein branch] = also wird [mein branch] mit dem origin von 8.0 versorgt?

zweite Ueberlegung: die Aenderungen in .gitignore sind 3 Folder, die ich hinzugefuegt habe. Das habe ich gemacht um sicher zu stellen, das diese bei allen remote aktionen ignoriert werden.
Diese 3 Ordner sind kein bestandteil des original repositories (also nicht 'gestaged', committed, oder sonstwas) und sollen es auch nicht sein.

Angenommen ich nehme die 3 aus .gitignore wieder raus wuerde git status diese wohl melden aber darueberhinaus koennte weder 'fetch', pull' oder 'merge' Daten aendern, oder ueberschrieben, richtig? So gesehen waeren die Eintraege in .gitignore ja vielleicht gar nicht noetig. Somit gibt es keinen Konflikt mehr, lediglich eine Meldung per git status, die man getrost ignorieren kann

Im Uebrigen kann man per git submodule auch gestapelte Repositories sauber voneinander trennen (separater Upstream, Tree, etc.).

Das hoert sich nach der elegatesten Loesung an, scheint mir aber auch ein Plus an komplexitaet mitzubringen, die ich (noch) lieber vermieden moechte

[vrms]

Vielleicht wäre es eine gute Idee einfach eine eigene Branch des Repos zu erstellen. ...
Alle Änderungen die Du lokal vornimmst erledigst Du innerhalb dieser Branch.

ich bin aktuell im branch 8.0 meines remotes. Mal angenommen ich mache mit

Code: Alles auswählen

git branch 8.0 [mein branch]

meinen eigenen lokalen branch (der remote nicht existiert und auch nicht existieren wird weil ich gar keinen Schreibzugriff auf das remote habe [und diesen auch nicht brache/will])
wie kann ich dann [mein branch] naechstes Mal mit den Daten von remote origin 8.0 versorgen?

Code: Alles auswählen

git checkout [mein branch]
git pull origin 8.0

etwa? (also meine logik hier waere: im moment in dem ich git sage von branch 8.0 zu pullen sitze in [mein branch] = also wird [mein branch] mit dem origin von 8.0 versorgt?

zweite Ueberlegung: die Aenderungen in .gitignore sind 3 Folder, die ich hinzugefuegt habe. Das habe ich gemacht um sicher zu stellen, das diese bei allen remote aktionen ignoriert werden.
Diese 3 Ordner sind kein bestandteil des original repositories (also nicht 'gestaged', committed, oder sonstwas) und sollen es auch nicht sein.

Angenommen ich nehme die 3 aus .gitignore wieder raus wuerde git status diese wohl melden aber darueberhinaus koennte weder 'fetch', pull' oder 'merge' Daten aendern, oder ueberschrieben, richtig? So gesehen waeren die Eintraege in .gitignore ja vielleicht gar nicht noetig. Somit gibt es keinen Konflikt mehr, lediglich eine Meldung per git status, die man getrost ignorieren kann

Im Uebrigen kann man per git submodule auch gestapelte Repositories sauber voneinander trennen (separater Upstream, Tree, etc.).

Das hoert sich nach der elegatesten Loesung an, scheint mir aber auch ein Plus an Komplexitaet mitzubringen, die ich (noch) lieber vermeiden moechte wen moeglich (also das Obige funktioniert)

[Liffi]

Your local changes of the following file would be overwritten by merge:
.gitignore
Please, commit your changes or stash them before you can merge

Commite deine Änderung lokal. Dann kann git auch mergen.

[catdog2]

Ignores, die du Lokal haben willst kannst du in .git/info/exclude packen, siehe: http://git-scm.com/docs/gitignore

[vrms]

Ignores, die du Lokal haben willst kannst du in .git/info/exclude packen, siehe: http://git-scm.com/docs/gitignore

ich dachte erst dann haette ich das gleiche Problem mit der ./git/info/exclude. Aber ich nehme mal an die ist durch den Eintrag

Code: Alles auswählen

# dotfiles
.*
!.gitignore

in meiner .gitignore vom Tracken, ausgeschlossen (also durch den '.' vor .git/..../....), sehe ich Das richtig?

EDIT: ja das scheint so zu funktionieren

Problem, das ich noch habe ist: wie kriege ich meine .gitignore wieder in den Originalzustand (den ich ja brauche um keinen Konflikt zu kreieren. Habe versucht die Zeilen, die ich hinzugefuegt habe manuall zu entfernen, git status zeigt .gitignore aber immer noch als 'modified' an.

[Liffi]

Problem, das ich noch habe ist: wie kriege ich meine .gitignore wieder in den Originalzustand (den ich ja brauche um keinen Konflikt zu kreieren. Habe versucht die Zeilen, die ich hinzugefuegt habe manuall zu entfernen, git status zeigt .gitignore aber immer noch als 'modified' an.

git checkout .gitignore.

[vrms]

wie kriege ich meine .gitignore wieder in den Originalzustand (den ich ja brauche um keinen Konflikt zu kreieren?

git checkout .gitignore.

standard syntax ist doch git checkout [brachname], was mich in den branch [branchname] wechseln laesst (gesetzt den Fall man haette uberhaupt mehr asl einen branch, was in meinem Szenario nicht der Fall ist).

Also wuerden wir mit deinem Befehl (git checkout .gitignore) doch versuchen in den branch .gitignore zu wechseln (was ja ueberhaupt keinen Sinn macht, denn .gitignore ist ja ein file und kein branch. Ein branch .gitignore existiert nicht.

Also entweder hast du dich hier vertan oder es gibt noch ne 'Metaebene' von checkout, sie mir bisher verborgen war.

[vrms]

wahrscheinlich müsstest Du die Änderungen in .gitignore committen oder zurück nehmen, um die Fehler- bzw. Warnmeldung zu vermeiden.

mit welchen Befehl kann ich meine lokalen Aenderungen in .gitignore zuruecksetzen (und so, den Konflikt loesen)?

[TRex]

Code: Alles auswählen

git checkout -- .gitignore

[Liffi]

git checkout $file setzt ein File zurück, falls es das gibt und es keinen Branch gibt der so heißt. Ich hoffe einfach mal, dass es keinen Branch bei dir gibt, der .gitignore heißt.

[novalix]

git checkout $file setzt ein File zurück, falls es das gibt und es keinen Branch gibt der so heißt. Ich hoffe einfach mal, dass es keinen Branch bei dir gibt, der .gitignore heißt.

Das gilt so lange Du die Änderungen an .gitignore nicht comitted hast, m.a.W der git index noch unbeleckt von Deiner Arbeit ist.
Falls Du schon comitted hast, musst Du die Änderungen am Index rückgängig machen. Dazu gibt die manpage von git checkout ebenfalls ein Beispiel:

Code: Alles auswählen

The following sequence checks out the master branch, reverts the Makefile to two revisions back, deletes hello.c by mistake, and gets it back
           from the index.

               $ git checkout master             (1)
               $ git checkout master~2 Makefile  (2)
               $ rm -f hello.c
               $ git checkout hello.c            (3)

           1. switch branch
           2. take a file out of another commit
           3. restore hello.c from the index

Hast Du also fünf commits in master zu .gitignore durchgeführt, würde Dir

Code: Alles auswählen

git checkout master~5 .gitignore

die letzte Version vor Deinen commits zurückholen.

[vrms]

ja, ihr habt alle recht. git checkout -- .gitignore
Steht sogar so in meiner Fehlermeldung drin, hab ich letztendlich bemerkt

besten dank