Re: Merges without bases

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Aug 26, 2005, 04:09 UTC
Message-ID: <Pine.LNX.4.63.0508252333550.23242@iabervon.org>
In-Reply-To: <7vvf1tps9v.fsf@assigned-by-dhcp.cox.net>

On Thu, 25 Aug 2005, Junio C Hamano wrote:

Show 5 quoted lines

> One thing that makes me reluctant to recommend this "merging
> unrelated projects" business is that I suspect that it makes
> things _much_ harder for the upstream project that is being
> merged, and should not be done without prior arrangement; Linus
> merged gitk after talking with paulus, so that was OK.

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

Definitely post-1.0, of course.

Show 6 quoted lines

> Suppose the above "My Project" is published, people send patches
> for core GIT part to it, and you as the maintainer of that "My
> Project" accept those patches.  The users of "My Project" would
> be happy with the new features and wouldn't care less where
> their core GIT tools come from.  But how would _I_ pull from
> that "My Project", if I did not want to pull unrelated stuff in?

With the right info, the tools could be made to automatically generate suitable commits, because those files would be tracked by a separate index file and committed into a separate branch, which would then be reincluded (by reference) in the containing project.

	-Daniel
*This .sig left intentionally blank*