Interessant. Ich habe wohl etwas beim ersten Versuch vergessen, ich habe mal das Experiment nochmal durchgeführt.
Nun habe ich die gleichen Dateien wie du (bis auf xxx/Xx.java, das gibt es nicht mehr), und nachdem ich Hacking nach master gemerge habe, habe ich das Attribut, Equals(), HashCode() und getter in der NewClass.java.
Liegt es daran, dass NewClass.java und Xx.java den gleichen Sha-Hash haben (im branch Hacking) (weil beide 0bytes haben)?
Also ich habe die Klassen mit Eclipse angelegt und da hat XX gleich eine Main-Methode bekommen. NewClass allerdings nicht. Sprich die Dateien sind alle unterschiedlich. Dachte ich könnte auf github schnell ein Projekt veröffentlichen aber das finde ich leider nicht :-( Habe jetzt das ganze mal gezippt unter http://min.us/mWx7YYF9w zur Verfügung gestellt. Da kannst Du alle Schritte sehen die ich gemacht habe und versuchen es zu mergen. Der aktuelle Zustand ist ungemergt. Es gibt zwei Branches naming und Naming2, bei letzerem habe ich 2 mal commitet um es git leichter zu machen. Hacking fehlt, da der erste Merge fehlschlug. Wäre froh wenn mir jemand zeigt wo der Fehler liegt. Denn Github und die starke Verbreitung von git ist aus meiner Sicht ein klares plus, aber für Java ist es aus meiner Sicht eher zweite Wahl.
Nun ja, ich benutze jetzt Git seit 2 Jahren und Java schon länger und da gab es absolut keine Schwierigkeiten. Ich habe auch schon öfters aus Branches gemerged und Sachen gemacht. Ein Merge von 2000 LOC und 50 Dateien sind keine Probleme für git auch in Java nicht.
Das hängt halt immer sehr stark davon ab, wie oft eine Datei umbenannt und gleichzeitig geändert wird. Auch mit SVN kann man relativ problemlos mergen. Von daher habe ich mal ein Testszenario gewählt. Ob das für einen passt oder nicht muss man dann selber abschätzen. Bei Eclipse wird beispielsweise auch selten umbenannt. Da ist das Testszenario schlecht gewählt. Der Aspekt das viele Programmieren, aber nur wenige in den Hauptzweig einstellen, ist da wiederum sehr stark ausgeprägt, was sicher eine Stärke von git ist.
"touch" ist für Java-Klassen schon mal der falsche Ansatz.
Bei Java muss die Klasse innerhalb der .java-Datei genauso wie die Datei heißen. Der Inhalt der xxx/Xx.java wäre also: package xxx; public class Xx { }
Und der neue Inhalt von de/ppi/test/Foo.java wäre: package de.ppi.test; public class Foo { }
Ein "rename" (eigentlich ein Refactoring) der Klasse führt also nicht nur dazu, dass der Dateiname ein anderer ist, sondern auch der Inhalt und damit der SHA-Hash.
Interessant. Ich habe wohl etwas beim ersten Versuch vergessen, ich habe mal das Experiment nochmal durchgeführt.
Nun habe ich die gleichen Dateien wie du (bis auf xxx/Xx.java, das gibt es nicht mehr), und nachdem ich Hacking nach master gemerge habe, habe ich das Attribut, Equals(), HashCode() und getter in der NewClass.java.
Liegt es daran, dass NewClass.java und Xx.java den gleichen Sha-Hash haben (im branch Hacking) (weil beide 0bytes haben)?
Hier sind meine Schritte:
Also ich habe die Klassen mit Eclipse angelegt und da hat XX gleich eine Main-Methode bekommen. NewClass allerdings nicht. Sprich die Dateien sind alle unterschiedlich.
Dachte ich könnte auf github schnell ein Projekt veröffentlichen aber das finde ich leider nicht :-(
Habe jetzt das ganze mal gezippt unter http://min.us/mWx7YYF9w zur Verfügung gestellt. Da kannst Du alle Schritte sehen die ich gemacht habe und versuchen es zu mergen. Der aktuelle Zustand ist ungemergt. Es gibt zwei Branches naming und Naming2, bei letzerem habe ich 2 mal commitet um es git leichter zu machen. Hacking fehlt, da der erste Merge fehlschlug. Wäre froh wenn mir jemand zeigt wo der Fehler liegt. Denn
Github und die starke Verbreitung von git ist aus meiner Sicht ein klares plus, aber für Java ist es aus meiner Sicht eher zweite Wahl.
Nun ja, ich benutze jetzt Git seit 2 Jahren und Java schon länger und da gab es absolut keine Schwierigkeiten. Ich habe auch schon öfters aus Branches gemerged und Sachen gemacht. Ein Merge von 2000 LOC und 50 Dateien sind keine Probleme für git auch in Java nicht.
Das hängt halt immer sehr stark davon ab, wie oft eine Datei umbenannt und gleichzeitig geändert wird. Auch mit SVN kann man relativ problemlos mergen. Von daher habe ich mal ein Testszenario gewählt. Ob das für einen passt oder nicht muss man dann selber abschätzen. Bei Eclipse wird beispielsweise auch selten umbenannt. Da ist das Testszenario schlecht gewählt. Der Aspekt das viele Programmieren, aber nur wenige in den Hauptzweig einstellen, ist da wiederum sehr stark ausgeprägt, was sicher eine Stärke von git ist.
"touch" ist für Java-Klassen schon mal der falsche Ansatz.
Bei Java muss die Klasse innerhalb der .java-Datei genauso wie die Datei heißen.
Der Inhalt der xxx/Xx.java wäre also:
package xxx;
public class Xx { }
Und der neue Inhalt von de/ppi/test/Foo.java wäre:
package de.ppi.test;
public class Foo { }
Ein "rename" (eigentlich ein Refactoring) der Klasse führt also nicht nur dazu, dass der Dateiname ein anderer ist, sondern auch der Inhalt und damit der SHA-Hash.