You said one thing that really doesn't make sense in context of git:
"inheriting files".  A branch is a pointer to a particular commit, and
a commit is a snapshot of the entire work tree at that point (along
with all the author metadata, message, and reference to the previous
commit).  The commits are static, once made, and a branch only moves
when you commit to it.

I also have no idea what you mean by "configuration manager" and "link
configurations or amalgamate them".

That said, what you're probably asking for is for one branch (A) to
automatically be merged into other branches (A1, A2). It's very
unlikely that you want to have this happen every single time you
commit to A, because it requires checking out A1 and A2 and performing
the merges.  (You can't do a merge without checking out the branch,
because the files have to be there to merge the content.)  This is
therefore a potentially time-consuming operation, not to mention the
possibility of conflicts, and it can't be done at all when you've
committed only some of your modifications, leaving others in the work
tree.  Besides, you don't really want a merge on A1 and A2 for every
commit in A.  This is pretty much the worst way to clutter your

Please have a look at this post from Junio Hamano's blog (he's the
current maintainer of git) before you get too crazy with your merge
philosophy. It's a very, very good description of a good way to handle
branches and merging:

Upshot as it applies to you: if A1 and A2 are development branches,
representing subtopics of A, you really don't want to be merging A
into A1 and A2.  But for the sake of providing an answer, I'll assume
you have a good reason to do this - perhaps these are deployment
branches, with A1 and A2 representing configuration differences that
will never be merged into A?

So if you still want to do this, all you really need is a script which
loops through the branches, checking them out and merging the
appropriate "parent".  How you implement this is kind of up to you -
perhaps a config file stores each branch's parent, perhaps it's based
on the names of the branches.  If there's more than one level of it
(master into A, A into A1 and A2), it's a recursion down the
configuration tree not just a simple loop.  You can make it smarter by
having it check to see if a merge is necessary before actually
checking out the branch, and so on.  All depends on your exact
circumstances.  And if somehow you really think you want to call this
every single time you update A, you could trigger it from the post-
commit and post-merge hooks.

Note: your diagrams show cherry-picking, not merging, but I really
think you probably want to merge. There's nothing gained by having
duplicate commits on every single branch.


On Feb 28, 10:55 pm, will <> wrote:
> Hello all
> I'm a recent convert to Git, and like what I've got so far.  Having
> said that, over the years I've come to apply a few hard-and-fast
> source and configuration management rules/processes that I know work
> (for me and in teams).
> I can't find how to do what I need to do in Get (yet) and it is more
> efficient to ask the collective mind, since I've checked the obvious
> sources and FAQ-s, etc.
> At this stage, I'd like to know how-to (or is it possible) to
> structure branches such that non-conflicting work on branch-A is
> inherited by a daughter-branch (say branch-A.01)?
> Example:
>     ---o---- master --- ...
>         \
>          *--- A ---o---o-------- XX -- ...
>                     \   \         |
>                      \   \        V
>                       \   *--- 2 --XX--- ...
>                        \          |
>                         \         V
>                          *---- 1 --XX--- ...
> If I chagve XX in branch-A that change is  'automatically' in branch-A.
> 1 and branch-A.2.
> The need is clear I hope -- I want say all bug fixes in branch-A to be
> seen in A.2 as well.  If anyont changes XX while working on the branch-
> A.2 then there's a conflict and you'd need to resolve it.
> Anyway what's the easiest (and minim of human action) that will work
> like that with Git?  I recall we had a lot of c-shell scripts to make
> SCC-s do like this 'one time'.  It is definitely worth doing.
> Because git is a configuration manager, it may not understand 'fine
> grain' stuff like inheriting files.  Is there a way to link
> configurations or amalgamate them?
> Thanks in advance,
>   Will

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to