Re: Merges without bases

From: Eric W. Biederman <ebiederm@xmission.com>
Date: Sep 9, 2005, 12:02 UTC
Message-ID: <m1hdcuo3df.fsf@ebiederm.dsl.xmission.com>
In-Reply-To: <7vzmr5gmb4.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 16 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> I'd still like to revive my idea of having projects overlaid on each
>> other, where the commits in the project that absorbed the other project
>> say, essentially, "also include this other commit, but any changes to
>> those files belong to that branch, not this one". That way, Linus could
>> have included gitk in git, but changes to it, even when done in a git
>> working tree, would show up in commits that only include gitk. (git
>> actually can handle this with the alternative index file mechanism that
>> Linus mentioned in a different thread.)
>
> Yes, I would love to see that cleanly done in a way that does not
> confuse uninitiated (not being sarcastic at all.  Just cheering
> up somebody with a better idea than I have --- I would be lost
> if I were to be tasked to do it by Emperor Penguin himself or
> somebody else ;-)).

I think when it comes to simplicity it would be better to have something that would filter all of the changes on a branch by pathname and create a branch against the original project with just those changes.

Then we can do the noop merge of that branch into the larger project, and we can merge that branch into the original project.

The nice part of doing it after the fact by just filtering changes is you don't have to plan ahead to handle that case, which should be a lot easier to handle.

The set of pathnames to filter could be easily stored in the .git metadata so doing repeatedly is straight forward.

Eric