Re: Merges without bases

Junio C Hamano [off-list ref] writes:

Daniel Barkalow [off-list ref] writes:

quoted

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