Proposal: better library management ideas (was: how to checkout proper submodules)

[Ian Lynagh]

On Mon, Jun 10, 2013 at 01:13:37PM +0200, Daniel Trstenjak wrote:
> 
> On Mon, Jun 10, 2013 at 11:45:22AM +0100, Ian Lynagh wrote:
> > Is this possible with subtrees?:
> > 
> > * Initially ghc's Cabal repo is at the same commit as upstream
> > * We make a local commit 123 in Cabal to fix some bug
> > * Cabal upstream makes a commit 456 to fix the same bug differently
> > * We jump to commit 456, in such a way that we don't end up merging
> >   with our 123 commit every time we pull from Cabal in the future
> 
> Yes.
> 
> Every repository that's added by git-subtree to your repository is
> represented as a separate branch. So everything that applies to the
> merging of branches also applies to the merging by git-subtree.

I didn't follow that.

Here's an example of what happens with just a plain git repo, with no
branches, submodules or subrepos involved:

-----8<----------8<----------8<----------8<-----

upstream$ git init
upstream$ echo content > file
upstream$ git add file
upstream$ git commit -a -m initial

$ git clone upstream ghc
$ cd ghc
ghc$ echo fix1 > file
ghc$ git commit -a -m fix1

upstream$ echo fix2 > file
upstream$ git commit -a -m fix2

ghc$ git pull --no-edit -X theirs

upstream$ echo feature1 > file
upstream$ git commit -a -m feature1

ghc$ git pull --no-edit -X theirs

upstream$ echo feature2 > file
upstream$ git commit -a -m feature2

ghc$ git pull --no-edit -X theirs

-----8<----------8<----------8<----------8<-----

At the end of this, you'll see that the ghc repo has a number of merge
commits.

I guess they may not cause any actual problems, but it's certainly nicer
not having them (which is what using submodules gives us).


Thanks
Ian
-- 
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/