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/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs