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