Re: Merges without bases

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Aug 26, 2005, 16:37 UTC
Message-ID: <Pine.LNX.4.63.0508261150320.23242@iabervon.org>
In-Reply-To: <46a038f905082602176f9eef5d@mail.gmail.com>

On Fri, 26 Aug 2005, Martin Langhoff wrote:

Show 16 quoted lines

> On 8/26/05, Junio C Hamano <junkio@cox.net> wrote:
> > 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?
>
> and then...
>
> > What I think _might_ deserve a bit more support would be a merge
> > of a foreign project as a subdirectory of a project.  Linus
>
> tla has an interesting implementation (and horrible name) for
> something like this. In Arch-speak, they are called 'configurations',
> a versioned control file that describes that in subdirectory foo we
> import from this other repo#branch.
>
> In cvs, you just do nested checkouts, and trust a `cvs update` done at
> the top will do the right thing;  and in fact recent cvs versions do.

The problem with both of these (and doing it in the build system) is that, when a project includes another project, you generally don't want whatever revision of the included project happens to be the latest; you want the revision of the included project that the revision of the including project you're looking at matches. That is, if App includes Lib, and you're looking at an App commit, you want to have the version of Lib that the commit was made with, not the latest version of Lib, which may not be backwards compatible across non-release commits, or, in any case, won't help in reconstructing a earlier state. I think a primary function of a SCM is to be able to say, "It worked last Friday, and it's broken now. What's different?" If the answer is, "On Saturday, we updated the included Lib to their version from Thursday, which is broken", it'll be really hard to track down without special tracking.

I think it's the lack of the special tracking, therefore, that makes this not a good feature in most SCMs, and makes them not better than having the build system do it (and potentially worse, if you've got your build system checking out a version specified in a version-controlled file). But I think that git can do better, including support for the required version sometimes being a locally modified one and sometimes being the official one when the local modifications have been accepted upstream.

	-Daniel
*This .sig left intentionally blank*