Proposal: better library management ideas (was: how to checkout proper submodules)
Daniel Trstenjak
daniel.trstenjak at gmail.com
Wed Jun 12 00:54:38 CEST 2013
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
-------------- next part --------------
#!/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 "$@"
More information about the ghc-devs
mailing list