Inheritance of files for parent/child branches

Inheritance of files for parent/child branches

[Adam Flott]

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

Re: Inheritance of files for parent/child branches

[Jeff King]

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

> 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.

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

Re: Inheritance of files for parent/child branches

[Adam Flott]

On Sat, 16 Feb 2008, Jeff King wrote:

> On Sat, Feb 16, 2008 at 11:32:01AM -0600, Adam Flott wrote:
>
>> 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.
>
> 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:

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

Re: Inheritance of files for parent/child branches

[Jeff King]

On Sat, Feb 16, 2008 at 12:33:42PM -0600, Adam Flott 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.

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