Git: rebase/squash auf "auseinanderliegende" commits

[Antoras]

Hallo,

folgendes Problem: Ich habe zwei commits c1 und c2, die ich gerne zusammenfügen würde. Zwischen diesen liegen jedoch mehrere andere commits cxN, die ich aber nicht anrühren möchte. Das sieht z.B. so aus:

c1
cx1
cx2
cx3
c2
cx4

Danach:

c1+c2
cx1
cx2
cx3
cx4

Bekommt man das irgendwie hin?

Was ich bisher versucht habe:

git rebase -i HEAD~5
# löschen der nicht relevanten Einträge auf
pick c1
squash c2
# commit message bestätigen

Das Problem an der Vorgehensweise ist, dass dann die dazwischenliegenden commits aus dem Log verschwunden sind.

PS: Die beiden commits sind nicht in einem eigenen branch und es gibt keine Konflikte mit den anderen commits.

[nman]

Antoras schrieb:

c1
cx1
cx2
cx3
c2
cx4

Einfach git rebase -i c1^ . Und dann im Editor so umschlichten, dass das nicht mehr so aussieht:

pick c1
pick cx1
pick cx2
pick cx3
pick c2
pick cx4

Sondern so:

pick c1
squash c2
pick cx1
pick cx2
pick cx3
pick cx4

Du kannst also einfach die Reihenfolge ändern; die Commits dazwischen lässt du einfach stehen.

[Antoras]

Super, dass das so einfach geht. Bei mir scheint es nur nicht korrekt zu funktionieren, bzw. ich kann es nicht überblicken ob es korrekt funktioniert.

Ich habe zuvor einige git resets gemacht (und bin damit mehrmals in der commit-liste vor und zurück gesprungen), nun scheint es so, dass es ein paar commits gibt, die neuer sind als die, die ich gerade zusammenführen möchte. Zumindest werden nach einem push auf github noch andere commits angezeigt, die da überhaupt nicht sein sollten.

Typisch Anfänger hab ich da wohl mein repo total verknotet - kann mir jemand Befehle nennen, mit denen ich mir einigermaßen einen Überblick verschaffen kann was ich da falsch gemacht habe bzw. wie ich das irgendwie wieder gerade biegen kann?

[nman]

Wenn du das Repo schon gepublished hast, solltest du nicht mehr rebasen, sonst schießt du irgendjemandem die Codebase unter den Füßen weg.

Mach mal ein git clone und schau dann, ob die Commits noch da sind. Wahrscheinlich cached GitHub das einfach nur aggressiver bzw. hat die Commits noch nicht garbage collected.

[Antoras]

nman schrieb:

Wenn du das Repo schon gepublished hast, solltest du nicht mehr rebasen, sonst schießt du irgendjemandem die Codebase unter den Füßen weg.

Das läuft noch alles auf meinem eigenen fork, also kann nicht viel passieren.

nman schrieb:

Mach mal ein git clone und schau dann, ob die Commits noch da sind. Wahrscheinlich cached GitHub das einfach nur aggressiver bzw. hat die Commits noch nicht garbage collected.

Glaube nicht, dass das an denen liegt. Aber kann ich ja wirklich mal ausprobieren.

[nman]

Antoras schrieb:

Das läuft noch alles auf meinem eigenen fork, also kann nicht viel passieren.

Doch, wenn er nicht privat ist, natürlich.

Beispiel:

• git clone git://github.com/antoras/foobar.git
• *bastelbastel*
• Antoras rebased sein öffentliches Repo.
• Boom. Ich kann mein Repo nicht mehr ohne viel, viel Arbeit zurückmergen bzw. Deine Änderungen pullen.

Glaube nicht, dass das an denen liegt. Aber kann ich ja wirklich mal ausprobieren.

Hatte ich schon ein paarmal. Wenn deine Commits in der Ausgabe von git-log nicht mehr angezeigt werden, bei GitHub aber schon noch, dann liegt das an GitHub.

[Antoras]

nman schrieb:

Antoras schrieb:

Das läuft noch alles auf meinem eigenen fork, also kann nicht viel passieren.

Doch, wenn er nicht privat ist, natürlich.

Beispiel:

• git clone git://github.com/antoras/foobar.git
• *bastelbastel*
• Antoras rebased sein öffentliches Repo.
• Boom. Ich kann mein Repo nicht mehr ohne viel, viel Arbeit zurückmergen bzw. Deine Änderungen pullen.

Wie funktioniert das mit einem merge, wenn man nur clont aber keinen eigenen fork erstellt? Mein fork ist doch für jeden anderen schreibgeschützt?

nman schrieb:

Glaube nicht, dass das an denen liegt. Aber kann ich ja wirklich mal ausprobieren.

Hatte ich schon ein paarmal. Wenn deine Commits in der Ausgabe von git-log nicht mehr angezeigt werden, bei GitHub aber schon noch, dann liegt das an GitHub.

Ok, ich kann bzw. will das jetzt nicht mehr überprüfen, da ich das Problem mit Hilfe eines anderen commiters gelöst bekommen habe. Er hat mir mehr oder weniger eine Schritt für Schritt Anleitung gegeben wie ich mein Repo reparieren kann. Das sah so aus:

So, I would suggest you to save your work on a branch different than master (that's actually good git usage ;)). So, from the branch that contains your changes (I believe it's master), do something like:

$ git checkout -b temp

That should create a new branch named `temp` and you should see your commits. If that's the case, then push this branch to your remote, just to be sure you wan't loose it, i.e., `git push origin temp`

Then, delete your local master branch `git branch -D master` and checkout the one from the original scala-ide repo:

$ git fetch upstream
$ git checkout -t upstream/master

And now you should 1) create a new branch, 2) cherry-pick your commits. Hopefully, that will work.

Danach konnte ich die beiden commits nach folgender Art squashen:

$ git checkout -b issue/find-ref-for-lazy-vals
$ git cherry-pick 8a31a7044210931311a041f46c2317292347067e
$ git cherry-pick d2b6ffa503c7a383e64d326607fa9e250eeb6f06
$ git rebase -i HEAD~2

Im rebase die beiden picks

pick 8a31a70 ...
pick d2b6ffa

zu

pick 8a31a70 ...
squash d2b6ffa

ändern. Das scheint perfekt funktioniert zu haben.

[nman]

Antoras schrieb:

Wie funktioniert das mit einem merge, wenn man nur clont aber keinen eigenen fork erstellt? Mein fork ist doch für jeden anderen schreibgeschützt?

Nein, das meinte ich nicht. Ich kann dann deine Aenderungen nicht mehr mergen und ich kann nicht zu deinem Master rebasen und dir dann einen Pull-Request schicken. Dh. ich habe ein Repo, mit dem ich weder vor noch zurueck kann, ohne viel manuell herumzubasteln.

Das scheint perfekt funktioniert zu haben.

Ja, sollte beides das gleiche Ergebnis haben.

[Antoras]

nman schrieb:

Nein, das meinte ich nicht. Ich kann dann deine Aenderungen nicht mehr mergen und ich kann nicht zu deinem Master rebasen und dir dann einen Pull-Request schicken. Dh. ich habe ein Repo, mit dem ich weder vor noch zurueck kann, ohne viel manuell herumzubasteln.

Jetzt habe ich mehr Ahnung von git und versuche die Fehler in Zukunft zu vermeiden, damit ich mir da keine Sorgen darum machen muss.