Inheritance of files for parent/child branches

The only redeeming feature in AccuRev was the ability to an use inheritance for files in streams (nearly analogous to branches). While this idea in the SCM world sounds strange, is there anything in git land that could mimic this sort of behavior?

In case, "inheritance for files..." isn't clear, what I would like to accomplish is: have a branch "parent" with multiple "children" branches (which may have descendents of their own). If a file is committed to the parent branch, then the all the descendents would receive the same update without manually cherry-picking the commit across all the branches.

Adam

On Sat, Feb 16, 2008 at 11:32:01AM -0600, Adam Flott wrote:

Wouldn't that just be a merge of the parent branch into the child branch? Which really isn't any different than cherry-picking, except that you retain the history instead of picking the one patch. In both cases, you are saying "take the differences in the parent tree between point X and point Y, and merge them into what I have now." In the case of cherry pick, you are saying that X is really Y^. In the case of a merge, you are saying that X is "the last point parent and child merged" (.e., git merge-base parent child).

It won't happen _automatically_, though, and I don't think it should (since each merge may have conflicts). But you could probably accomplish what you want by cascading the merges. Something like:

  git checkout parent
  hack hack hack
  git commit -a -m whatever
  cascade_merge() {
    parent=$1
    for child in `somehow lookup the child branches of $parent`
    do
      git checkout $child
      git merge $parent
      cascade_merge $child
    done
  }
  cascade merge parent

This snippet is illustrative, not functional; recursion in the shell will stomp on the variables. But more importantly, the "git merge" may actually require human intervention. So you need to stop, let the user fix up the working tree, and then continue.

-Peff

On Sat, 16 Feb 2008, Jeff King wrote:

Your example is basically the only solution I could think of that would work with git. This repository will be for configuration files, where I want the parent to always "win" with conflicts.

I'll use your example as a basis for something and see if I can come up with a proof of concept that won't backfire on me in the future.

Adam

On Sat, Feb 16, 2008 at 12:33:42PM -0600, Adam Flott wrote:

Ah. That's much easier then. Instead of doing a real merge, you can just checkout from the parent every file that has changed between the merge base and the parent, and then make a new merge commit based on those contents. And then the "merge" always succeeds.

-Peff