[RFD] Overlapping projects

[RFD] Overlapping projects

[Daniel Barkalow]

It seems to me like projects like cogito which are based on a core which
is itself a project and which is also part of other projects would benefit
from some sort of support.

In particular, it would be nice if Linus could pull the changes to the
core without getting the wrapper programs at all.

I'm thinking something like having a head for cogito and a head for git in
the same repository, where the trees for git only have the core files, and
the commits for cogito have, in addition to a tree with only the
cogito-specific files, a reference to a git commit that they include.

It seems to me like this area contains a brilliant idea that I haven't
had so far, and maybe someone can come up with it.

	-Daniel
*This .sig left intentionally blank*

Re: [RFD] Overlapping projects

[Junio C Hamano]

>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:

DB> It seems to me like projects like cogito which are based on a core which
DB> is itself a project and which is also part of other projects would benefit
DB> from some sort of support.

I personally feel supporting that kind of development directory
structure is backwards, and Cogito is a very bad example for it.

Things could have been structured in such a way to have Cogito
and core GIT in separate directories hanging from the top level,
and Cogito can borrow pieces of GIT from the neighboring
directory if it needed to build specialized binary using
libgit.a.  Unless Petr makes changes to core GIT that is _too_
specific for general use (read: does not meet Linus' taste), we
should be able to port the nicer changes made to the core GIT
for Cogito's use (like git-ls-files "-t" flag) back to core GIT
and there would not be a reason for Cogito to keep carrying its
own copy of modified core GIT.

DB> In particular, it would be nice if Linus could pull the
DB> changes to the core without getting the wrapper programs at
DB> all.

Yes, that is a very desirable arrangement.

However, that does not require to keep them in the same
repository.  Cogito _could_ have been shipped this way:

                      + (top-level)
                     / \
                    cg git
     (Cogito sources)   (copy of core GIT files)
     .git/ for Cogito   .git/ for core GIT
     only

with an instruction like:

    The tarball contains cg and git subdirectories.  cg part
    implements Cogito, and git part is a copy of recent if not
    latest core GIT.  Go to cg and type "make" to build both of
    them.  Theoretically they can be independently updated to
    the latest but preferred combination is to use at least this
    release of core GIT to use this version of Cogito ...

Maybe I am being too idealistic.  I do not deny there are people
who want to manage "projects within projects" structure and
other people like CVS, subversion and arch do support that
style.  My impression about them is that the way CVS does it via
CVSROOT/modules looked like an ugly hack bolted onto it as an
afterthought, external stuff subversion uses did not feel quite
right (although nicer than what CVS does), and what arch does
was more reasonable but the boundary between SCM and build
environment was quite blurry there.  And many people "wanting to
do so" and other people "supporting doing it" do not necessarily
make that right.

Re: [RFD] Overlapping projects

[Daniel Barkalow]

On Mon, 9 May 2005, Junio C Hamano wrote:

> >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> DB> It seems to me like projects like cogito which are based on a core which
> DB> is itself a project and which is also part of other projects would benefit
> DB> from some sort of support.
> 
> I personally feel supporting that kind of development directory
> structure is backwards, and Cogito is a very bad example for it.

The directory structure is definitely awkward. I'd personally put cogito
stuff in a separate directory. But that's a matter of which paths belong
to which commit.

> Things could have been structured in such a way to have Cogito
> and core GIT in separate directories hanging from the top level,
> and Cogito can borrow pieces of GIT from the neighboring
> directory if it needed to build specialized binary using
> libgit.a.  Unless Petr makes changes to core GIT that is _too_
> specific for general use (read: does not meet Linus' taste), we
> should be able to port the nicer changes made to the core GIT
> for Cogito's use (like git-ls-files "-t" flag) back to core GIT
> and there would not be a reason for Cogito to keep carrying its
> own copy of modified core GIT.
> 
> DB> In particular, it would be nice if Linus could pull the
> DB> changes to the core without getting the wrapper programs at
> DB> all.
> 
> Yes, that is a very desirable arrangement.
> 
> However, that does not require to keep them in the same
> repository.  Cogito _could_ have been shipped this way:
> 
>                       + (top-level)
>                      / \
>                     cg git
>      (Cogito sources)   (copy of core GIT files)
>      .git/ for Cogito   .git/ for core GIT
>      only
> 
> with an instruction like:
> 
>     The tarball contains cg and git subdirectories.  cg part
>     implements Cogito, and git part is a copy of recent if not
>     latest core GIT.  Go to cg and type "make" to build both of
>     them.  Theoretically they can be independently updated to
>     the latest but preferred combination is to use at least this
>     release of core GIT to use this version of Cogito ...

But when Petr adds something to the core, intended for eventual inclusion
in the mainline, and uses it in cogito, this breaks everything, because
then people have to know to pull both the latest cogito and the latest git
from him. If the new git isn't backwards-compatible, then someone building
an old cogito would have to somehow find the matching old git.

This is far worse than just including git and sending Linus patches; the
only way to make this manageable would be to suspend cogito until git was
completely finished.

The important thing, I think, is being able to connect a Cogito with the
git it uses, while both are unstable and under active development. It
would be nice to be able to have the obvious things happen when you pull
the latest cogito and check it out, and when you commit with changes to
files from each of them, but that's less important.

	-Daniel
*This .sig left intentionally blank*

Re: [RFD] Overlapping projects

[Junio C Hamano]

>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:

>> ...
>> with an instruction like:
>> 
>> ...  Theoretically they can be independently updated to
>> the latest but preferred combination is to use at least this
>> release of core GIT to use this version of Cogito ...

DB> But when Petr adds something to the core, intended for eventual inclusion
DB> in the mainline, and uses it in cogito, this breaks everything, because
DB> then people have to know to pull both the latest cogito and the latest git
DB> from him. If the new git isn't backwards-compatible, then someone building
DB> an old cogito would have to somehow find the matching old git.

I think we are in agreement and saying the same thing.  Yes, if
people wants to do mix and match, they should know what they are
doing.

Also I do not see any reason not to have GIT that comes from
Cogito additional stuff while Linus tree lags behind, which in a
sense already has been the case for some commands.  Separating
directories would make things easier to manage, not harder.

Anyhow let's wait and see what Petr does.  He said he has been
preparing core backports earlier.  No point arguing about his
tree without helping him.

Re: [RFD] Overlapping projects

[Sean]

On Tue, May 10, 2005 12:56 am, Daniel Barkalow said:
> It seems to me like projects like cogito which are based on a core which
> is itself a project and which is also part of other projects would benefit
> from some sort of support.
>
> In particular, it would be nice if Linus could pull the changes to the
> core without getting the wrapper programs at all.
>
> I'm thinking something like having a head for cogito and a head for git in
> the same repository, where the trees for git only have the core files, and
> the commits for cogito have, in addition to a tree with only the
> cogito-specific files, a reference to a git commit that they include.
>
> It seems to me like this area contains a brilliant idea that I haven't
> had so far, and maybe someone can come up with it.
>

That sounds like a great idea and shouldn't need any brilliant ideas to
implement.  Just need to push a little more multi-head handling down into 
 git.  The Cogito build process could then include a checkout of the
git-core branch.  Would be much cleaner than the way it is handled now.

Sean