[Scummvm-devel] Interspective Innocent Engine

[Tarek Soliman]

On Sun, Jul 03, 2011 at 12:04:54AM +0100, D G Turner wrote:
>   P.S. For anyone needing to do something similar and wondering about
>   the required git commands, they were as follows:
Thanks for sharing this. This is really cool.
>   (Starting from a fork of scummvm checked out as scummvm-digitall)
>   * git add remote innocent-original git://repo.or.cz/scummvm-innocent.git
>   * git fetch innocent-original master:innocent-original
>   * git checkout master
>   * (using gitk or git log to find the point of branching
>      i.e. in this case svn-r43068... find the git-id for this in master,
>      not in innocent-original)
>   * git branch -a innocent <id-of-branch-point>
>     (in this case : 8820b6166ecc5f2c76e926aefdbf4d3ad6f2f062)
This is really key. I'll discuss at the bottom. [1]
>   * git clean -f (WARNING: This removes _all_ non versioned files from
>     the tree, used to prevent merge issues on the cherry pick later)
>   * (using gitk or git log find the ids of the first commit on the
>      innocent-original branch after the branch point and the last
>      commit)
>     (in this case c15c4013dcae120aa6c6fa51dde4fc6fd7df448a and
>      11ae6499454c0e2b790c807e269f5dc56390257e)
>   * (still on innocent branch):
>     git cherry-pick
> c15c4013dcae120aa6c6fa51dde4fc6fd7df448a..11ae6499454c0e2b790c807e269f5dc56390257e
>     i.e. cherry pick all the commits from the "innocent-original" branch
> since the branching point onto the new "innocent" branch which is based
> on our git repo history.
>     WARNING: This will require a significant amount of time, and I think
> a significant amount of (transient) disk space to complete.
I am assuming this cherry-picking would flatten (linearize not squish) the history tree.
I would have gone with git-format-patch and git-am the patches rather than having 2 repos in 1 repo.
>   * git -D innocent-original (remove the original repo commit history -
>   mainly to save disk space, but this will not be pushed anyway and has
>   not dependencies)
>   * git gc (This will clean up the removed references from the previous
>   deletion and will also ensure the new commits are compressed)
>   * git diff (--stat)
> c15c4013dcae120aa6c6fa51dde4fc6fd7df448a..11ae6499454c0e2b790c807e269f5dc56390257e
>   (Review changes for any changes to base code which are not intended to
> be kept after merge with master i.e. severe conflict)
>   * (Normal commit to remove / modify these)
>   * git merge master (This merges the changes since the branching point
>     on master to the "innocent" branch)
>   * (The previous command may get minor conflicts to deal with as
>     normal, by "git mergetool" and finalise with "git commit")
>   * (Normal commit to add engine compilation fixes required for master.

[1] : So the history would look like N commits in a row based on the branch point
As if there not a single pull done until the latest commit.
I imagine that in reality a lot of pulls were done right?
If so, that means a lot of these commits don't compile, making things like bisect tricky.

I have had to deal with similar problems and the 2 options are
a) what you did (minus the brilliant "find the correct branch point")
b) squish everything into 1 commit and lose history

Both options suck for bisecting inside the "feature" but at least the second option doesn't ruin bisect for the whole project.

This is a more generic concern rather than a scummvm-specific one.
-- 
Tarek