Re: [PATCH/RFC 1/2] Add 'git subtree' command for tracking history of subtrees separately.

From: Avery Pennarun <apenwarr@gmail.com>
Date: Apr 30, 2009, 14:32 UTC
Message-ID: <32541b130904300732i691800f5kecc2f845584071c1@mail.gmail.com>
In-Reply-To: <20090430085853.GA21880@pvv.org>

On Thu, Apr 30, 2009 at 4:58 AM, Finn Arne Gangstad <finnag@pvv.org> wrote:

Show 12 quoted lines

> On Wed, Apr 29, 2009 at 10:27:44PM -0400, Avery Pennarun wrote:
>> 'git subtree' provides an alternative mechanism, based around the
>> 'git merge -s subtree' merge strategy.  Instead of tracking a submodule
>> separately, you merge its history into your main project, and occasionally
>> extract a new "virtual history" from your mainline that can be easily merged
>> back into the upstream project.  The virtual history can be incrementally
>> expanded as you make more changes to the superproject.
>
> We have the exact same situation. I wanted to attack this from the
> other end though, make submodules useable also in this scenario. The
> subtree solution seems to be much easier to do in git, so maybe this
> is a better approach!

Sounds like your thought process is similar to mine :) I spent a lot of time trying to figure out how to convince submodules to work the way I wanted, until I eventually realized that subtrees were already a lot closer.

Show 11 quoted lines

> Let's say you have three different projects that all use some shared
> modules, The following operations should all be easy and fully
> supported:
>
> a) Modify project + some shared modules (in your project) with single commit
> b) Push project + shared modules (for your project)
> c) Push modifications to shared modules
> d) Merge upstream version of shared modules into your project.
>
> My quick analysis:
> Your subtrees: a & b are easy, c & d are painful

My *attempt* with git-subtree was to make all four operations easy. It's up to you to decide whether I succeeded :)

a) Modify-and-commit: just git commit

b) Push project+shared: just git push

c) Push shared changes only:
      # Should we try to make a simpler single command for this?
      # The problem is: I suspect people will normally want to review the
      # git subtree split output before pushing it anywhere, so combining
      # the split/push operations may not be wise.
      git push shared-remote $(git subtree split --prefix=shared-dir):master

d) Merge upstream changes of shared module:
      git subtree pull --prefix=shared-dir shared-remote master
    or
      git fetch shared-remote master
      git subtree merge --prefix=shared-dir FETCH_HEAD

Have fun,

Avery