Frage

Ich habe einen Git Repository (die mehr oder weniger Projektentwicklung) und getrennte Quellen (nur einen Tarball mit wenigen Dateien), die vor einiger Zeit gegabelt hat (tatsächlich irgendwo in Jahr 2004 oder 2005).

Die Quellen, aus Tarball haben ziemlich viele Veränderungen durchgemacht, von denen Ich mag würde einige zu übernehmen. Nun ist die Frage -. Wie Sie herausfinden, was tatsächlich der Verzweigungspunkt für die geänderten Quellen war minimal diff zu bekommen, was dort passiert ist

Also, was ich im Grunde will, ist in git Geschichte zu finden, wo der Code am ähnlichsten ist Tarball von Quellen die ich habe. Und ich will nicht, dass manuell tun.

Es ist auch erwähnenswert, dass die geänderten Quellen nur von Dateien Teilmenge umfassen und haben einige Dateien in mehrere aufgeteilt. Doch der Code, der in es scheint nur kleine Änderungen und einige Ergänzungen zu erhalten.

Wenn Sie mit, dass selbst spielen wollen, ist der Tarball mit Quellen hier und Git gehostet wird unter Gitorious : git://gitorious.org/gammu/mainline.git

War es hilfreich?

Lösung

Im allgemeinen Fall, würden Sie tatsächlich untersuchen müssen jede einzelne begehen, weil Sie nicht wissen, wenn Sie einen großen diff in einem haben könnte, diff klein die nächste, dann noch eine riesige diff, dann ein Medium diff ...

Ihre beste Wette ist wahrscheinlich zu sein, sich Dateien auf bestimmte zu begrenzen. Wenn Sie nur eine einzelne Datei zu prüfen, sollte es nicht lange dauern, um durchlaufen alle Versionen dieser Datei (Verwendung git rev-list <path> eine Liste zu bekommen, so dass Sie nicht testen, müssen alle begehen). Für jede begehen, die die Datei geändert, können Sie die Größe des diff überprüfen und ziemlich schnell ein Minimum finden. Tun Sie dies für eine Handvoll Dateien, hoffentlich werden sie zustimmen!

Die beste Möglichkeit, sich für die diffing einzurichten ist eine temporäre durch einfaches Kopieren in Ihrem Tarball verpflichten zu machen, so können Sie einen Zweig namens tarball zum Vergleichen gegen. Auf diese Weise könnten Sie dies tun:

git rev-list path/to/file | while read hash; do echo -n "$hash "; git diff --numstat tarball $hash path/to/file; done

eine schöne Liste aller Commits mit ihren diff Größen zu bekommen (die ersten drei Spalten SHA1, die Anzahl der Zeilen hinzugefügt, und die Anzahl der Zeilen entfernt werden). Dann konnte man nur eine Pipe auf in awk '{print $1,$2+$3}' | sort -n -k 2, und Sie würden eine sortierte Liste von Commits und ihre diff Größen haben!

Wenn Sie nicht selbst auf eine kleine Handvoll von Dateien Test begrenzen, könnte ich versucht sein, von Hand implementieren etwas ähnliches wie git-bisect - nur versuchen, Ihren Weg zu verengen auf einen kleinen diff, die Annahme, dass in allen Wahrscheinlichkeit, Commits in der Nähe zu Ihrem besten Fall haben auch kleinere diffs und Commits weit davon entfernt größere diffs haben. (Irgendwo zwischen Newton-Verfahren und eine voll auf Binär / Rastersuche, wahrscheinlich?)

Edit: Eine andere Möglichkeit, schlug in Douglas' Antwort , wenn Sie, dass einige Dateien denken könnte identisch zu denen in einigen begehen, ist Hash a href sie mit <= "http://www.kernel.org/pub/software/ scm / git / docs / git-Hash-object.html“rel = "nofollow noreferrer"> git-hash-object , und dann sehen, was in Ihrer Geschichte verpflichtet, dass blob hat. Es gibt eine Frage mit einigen ausgezeichneten Antworten darüber, wie das zu tun. Wenn Sie dies mit einer Handvoll von Dateien zu tun - vorzugsweise solche, die häufig geändert haben -. Sie könnten in der Lage sein, das Ziel zu verengen begehen ziemlich schnell

Andere Tipps

Nicht eine große Lösung, aber eine Vermutung von denen Revisionen zu bekommen, es könnte sein: Es wird angenommen, dass einige der Dateien im Tarball nicht, da sie verzweigt wurden geändert. Führen git Hashobjekt gegen jede Datei im Tarball, dann für die Dateien im Repository suchen nofollow mit git show . Dann versuchen, die Commits, unter denen diese Dateien enthalten waren, möglicherweise mit git Whatchanged . Die Antwort auf Ihre Frage könnte dann der Commit mit den häufigsten Dateien, aber es wird immer noch ein bisschen hit and miss sein.

auf, was araqnid sagte ich mit 9c6c864426bf88429e77c7e22b5aa78e9295b97a kam (nur bat um Material zwischen 0.61.0 und HEAD) ist dies wahrscheinlich nicht die beste), die Sie vielleicht besser mit so etwas wie

git rev-list --no-merges --all | while read rev; do patchsize=$(git diff $rev | wc -c); echo $patchsize $rev; done | sort -n | less

vorausgesetzt, Sie haben den Tarball in git importiert und haben diese Revision ausgecheckt (I tat dies durch untaring und dann

git init
git add .
git commit -m "import tarball"
git remote add origin git://gitorious.org/gammu/mainline.git

So, nachdem Sie das tun, und der Lauf der darüber ausgeben sollte die Größe aller Diffs in der Reihenfolge der patchsize aufsteigend (der erste wird 0 sein, da sie den aktuellen Kopf finden) dauert es eine lange Zeit dauern, ... aber es sollte die kleinste diff ...

finden

Wie war die Gabel gemacht? es war ein Klon, dass jemand anderes gemacht und hat dann ihre eigene Arbeit? wenn ja, dann ist das wirklich einfach. alles, was Sie tun müssen, ist eine lokale Niederlassung, dass zieht in dem Code von der Gabel zu erstellen. git wird die Abstammung der Astgabel zeigt auf eine der Festschreibungen von Ihrem ursprünglichen Repository sehen und wird sozusagen „die Punkte verbinden“ ... es wird die Geschichte von Ihrem ursprünglichen Repository auf die Gabel wieder an.

Sie sollten in der Lage sein, dies zu tun:

git remote add thefork git://wherever.it.lives/thefork.git

git fetch thefork

git branch -f thefork-branch thefork/branchname

git checkout thefork-branch

An dieser Stelle können Sie gitk laufen und die komplette Geschichte des Astgabel und Ihr lokales Repository sehen, und sehen, ob sie eine Verbindung herstellen oder nicht.

Importieren, dass Dateien im Tarball in eine git Revision, auf einem separaten Zweig oder eine völlig neue:. Der Position in der Revisionsgraph ist nicht wichtig, wir wollen es nur als ein Baum verfügbar

Jetzt für jede Revision im Master, nur diff gegen diesen Baum / Revision ( ‚importiert‘) und nur ausgegeben, wie groß der Unterschied ist. So etwas wie:

git rev-list master | while read rev; do patchsize=$(git diff $rev imported | wc -c); echo $rev $patchsize; done

So ist die Revision mit der kleinsten Patch Größe wird die „nächste“ sein, durch eine sehr grobe Daumenregel. (Eine identische Revision wird ein Patch Größe von 0 erzeugen, und alles andere wird sicherlich nicht Null sein, und je mehr, die sich geändert hat, desto größer ist).

Wenn Sie eine ungefähre Vorstellung haben, wo die Gabel aufgetreten ist, prüfen, mit Willen Manley git meld . (Siehe auch: Unterschiede anzeigen von Filialen mit meld ?).

Um dies zu tun, fügen Sie die Tarball Inhalte zu Ihrem Repository (die Sie ohnehin tun werden). Nach der Installation von Meld und git-meld, führte

git meld branch_from_tarball commit_to_check &

auf verschiedenen Commits, bis Sie das mit den geringsten Unterschiede finden. Dieser Befehl wird meld öffnen und die Änderungen im Verzeichnisbaum zwischen den angegebenen Commits sehen, mit identischen Dateien versteckt. Beispiel Screenshots:

Meld zeigt zwei sehr unterschiedliche Commits:
Ganz anders

Es werden zwei ähnliche Commits: ähnliche

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top