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 history! 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: http://gitster.livejournal.com/42247.html 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. Jeffrey On Feb 28, 10:55 pm, will <william.full.m...@gmail.com> 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 git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.