Verwendete Unit 'System.ImageList' kann nicht compiliert werden

[jaenicke]

Zitat von freimatz:

Man muss sich bei git schon anstrengen etwas kaputt zu machen.

Das geht sogar sehr einfach:
Vergiss vor dem Pull, dass noch lokale Änderungen da waren, dann bekommst du ggf. einen Konflikt. Wenn du den löst, zeigt dir TortoiseGit einen "Special Commit" an. Wenn du dann denkst, dass du doch die Änderungen gar nicht gemacht hast und welche rausnimmst, machst du leider die vorhergehenden Änderungen kaputt.

Klar, wenn man weiß, was man tut, passiert so etwas nicht, aber ich habe das schon erlebt (einige Wochen nach der Einführung von Git) und habe das dann im Repository korrigiert (es war auch niemand sonst da, der das hätte machen können).

Die Arbeitsanweisung, die ich mir dann überlegt habe, lautete, dass jeder zuerst das Staging nutzt, um lokale Änderungen wegzunehmen, dann pullt und dann die lokalen Änderungen wieder zurück holt. Dann gibt es ggf. auch Konflikte, aber die entstehen dann nur lokal und beim Committen sieht man wirklich nur die eigenen Änderungen, so dass das alles unproblematisch ist.

Zitat von Uwe Raabe:

Ich war ja lange Jahre überzeugter Mercurial-Nutzer und ich betrachte es immer noch als das ideale System für Einsteiger und Dummies (nicht abwertend gemeint), die ein einfach zu bedienendes und unkaputtbares System suchen.

Ja, das ist es. Ich persönlich mag Git lieber, aber ich weiß auch, dass es nicht narrensicher ist und man schon aufpassen muss, ob man das tut, was man meinte.

[himitsu]

Zitat von jaenicke:

Vergiss vor dem Pull, dass noch lokale Änderungen da waren

Oder vor dem Commit den Pull vergessen, dann sieht das Log auch schnell pervers aus (wenn man GIT aus Standard stehen hatt, was die Mergemethode betrifft)

Noch schlimmer wird es bei einem Merg und ganz besonders, wenn es da beim Merge zu Konflikten kam.
Da dann die Änderungen wieder auseinander zu bekommen
oder nicht ausversehn das Lokale mit dem Merge vermischt zu committen.

Zitat von freimatz:

Man muss sich bei git schon anstrengen etwas kaputt zu machen.

Bei SVN bekommt man nichts kaputt. (pull und push kann man auch nicht vergessen ... das ist quasi automatisch immer implizit dabei)
Im GIT geht es leichter, als man denkt ... samt löschen/überschreiben der kompletten Historie.

Ist aber immernoch besser, als gar keine Versionierung,
vor allem im Vergleich mit NICHTS, ZIPs oder Verzeichniskopien.