Hi Ian, > I guess they may not cause any actual problems, but it's certainly nicer > not having them (which is what using submodules gives us).
I don't quite understand how you should get rid of these merge commits by using submodules, because at the end every submodule is just a git repository and behaves in the same way as every other git repository for merges. You can get rid of these merge commit by using the '--rebase' option of git-pull. I put your git command lines into the attached script 'ghc_git_test'. Now you can get your version and the version using '--rebase' by calling: mkdir your_version rebase_version cd your_version ghc_git_test -X theirs cd ../rebase_version ghc_git_test --rebase -X ours You will certainly ask why it's 'ours' instead of 'theirs' for the rebase case, well, that's one of the quite counterintuitive things in the git user interface. Greetings, Daniel
#!/usr/bin/env bash mkdir upstream ghc cd upstream git init echo content > file git add file git commit -a -m initial cd .. git clone upstream ghc cd ghc echo fix1 > file git commit -a -m fix1 cd ../upstream echo fix2 > file git commit -a -m fix2 cd ../ghc git pull --no-edit "$@" cd ../upstream echo feature1 > file git commit -a -m feature1 cd ../ghc git pull --no-edit "$@" cd ../upstream echo feature2 > file git commit -a -m feature2 cd ../ghc git pull --no-edit "$@"
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
