Ich würde das wie einen normalen Fork abbilden, bei dem der Upstream "sehr große" Commits macht. D.h., dass du einen "upstream"-Branch pflegst, auf dem du immer die Releases von upstream einpflegst, und dann deine eigenen entweder auf die jeweils neuste Version rebased oder mit der neusten Version merged.
Siehe
man git-rebase
man git-merge
für schöne Grafiken, wie das dann im Git-Repository aussieht.
Für den Rebase-Ansatz wäre das in deinem Fall konkret das hier (ungetestet, am besten nach jedem Befehl den Stand des Git-Repositories kontrollieren mit git status und git log):
git checkout e2358d24 # das ist der Commit "Initial import from version 3.2.9"
git tag v3.2.9-upstream # einfach mal markieren, schadet nicht
git checkout -b upstream # neuen Branch "upstream" an genau dieser Stelle erstellen. Auf diesem Branch werden ab jetzt alle Änderungen des upstream getrackt
unpack_tarball # diese Funktion gibt es natürlich nicht. Hier müssen die Befehle hin, die den aktuellen Tarball wieder in das Git kopieren
git add .
git diff --staged # einmal anschauen, dass der neue commit auch sinnvoll aussieht
git commit -m "updating to 3.2.10" # dann den upstream code committen
git tag v3.2.10-upstream # markieren schadet nicht
# ab hier hast du ein Repository, das auf dem Branch "master" so aussieht, wie bisher und einen zusätzlichen Branch "upstream", der nur die Commits enthält, die 3.2.9 und 3.2.10 einpflegen
# jetzt kannst du entscheiden, wie du das mergen willst, ob du z.B. separate Branches für die verschiedenen Upstream-Versionen haben willst, etc.
# Für den Rebase-Fall:
git checkout master # wieder zurück auf master
git branch v3.2.9 # einen neuen Branch an der gleichen Stelle erstellen, um den Master zu "backuppen", da wir den gleich verändern
git rebase upstream # alle Commits auf den Branch "upstream" rebasen
