Re: [RFC] Support projects including other projects

I think that the core of your idea of recording "required
version" of the depended project (core GIT) in the depending
project (Cogito) is a very sound one.  GNU Arch folks do
something similar in their "package-framework" stuff.  

I however do not think that belongs to the core GIT nor even to
Cogito for that matter.  To me, it feels like this is a pure
build infrastructure issue.

I think you could arrange something like that with today's core
GIT tools, like this:

 - Tweak Cogito Makefile so that pure Cogito and core GIT are
   housed in separate subdirectories;

 - Add "required-git-pb" file to Cogito source as a tracked
   source file, and record the required version of git-pb there;

 - Arrange Cogito Makefile to make sure the subtree that has the
   core GIT side meets "required-git-pb" constraints.  The
   constraints could be "at least contains this one", "exactly
   this one".  The policy would be differnt from a depending
   project to another.  What happens if the requirements are not
   met is also up to the policy of that depending project.

On Wed, 11 May 2005, Junio C Hamano wrote:

I think that the core of your idea of recording "required
version" of the depended project (core GIT) in the depending
project (Cogito) is a very sound one.  GNU Arch folks do
something similar in their "package-framework" stuff.  

I however do not think that belongs to the core GIT nor even to
Cogito for that matter.  To me, it feels like this is a pure
build infrastructure issue.

If you think about it as git and cogito being entirely separate projects,
where users would be expected to have the right version of git most of the
time (or ever), this is true. But I think that cogito is as closely tied
to git as the kernel is to kbuild or kconfig; the difference is that git
is not solely available with cogito, like kbuild is solely available with
the kernel.

I think you could arrange something like that with today's core
GIT tools, like this:

 - Tweak Cogito Makefile so that pure Cogito and core GIT are
   housed in separate subdirectories;

 - Add "required-git-pb" file to Cogito source as a tracked
   source file, and record the required version of git-pb there;

 - Arrange Cogito Makefile to make sure the subtree that has the
   core GIT side meets "required-git-pb" constraints.  The
   constraints could be "at least contains this one", "exactly
   this one".  The policy would be differnt from a depending
   project to another.  What happens if the requirements are not
   met is also up to the policy of that depending project.

When a particular cogito commit is made, it is impossible to tell whether
the next git-pb will work with it; the current set of patches could be
rejected in mainline git, and different support for the same functionality
added which requires something different from cogito.

This also means that Petr can't really test changes to git before
commiting them (and a new cogito with the constraint changed), because the
cogito build system would then require him to use a version he's not
testing.

Also, either the user has to keep track of two projects without any system
support in the same directory structure and figure out how to follow the
instructions from the build system in getting the right version checked
out in the right place, or the build system is tied to a particular
wrapper layer.

I think your idea is theoretically possible, but that it is just too
impractical for anyone to ever actually use it. It's something that people
could do with CVS (and it would actually work better, due to CVS's
limitations making the issues simpler), but people don't.

	-Daniel
*This .sig left intentionally blank*

On Thu, 2005-05-12 at 15:19, Daniel Barkalow wrote:

If you think about it as git and cogito being entirely separate projects,
where users would be expected to have the right version of git most of the
time (or ever), this is true. But I think that cogito is as closely tied
to git as the kernel is to kbuild or kconfig; the difference is that git
is not solely available with cogito, like kbuild is solely available with
the kernel.

I tend to disagree with you on this point. Cogito and Git share
arelationship more akin to xorg and gnome and this is something I think
Linus intended so that it would be very easy to build a layer on top of
the git toolset. Cogito is great and it fills a need but give it time
and other implementations and tool sets will come along that may
supersede it.
-- 
James Purser
http://ksit.dynalias.com

On Thu, 12 May 2005, James Purser wrote:

On Thu, 2005-05-12 at 15:19, Daniel Barkalow wrote:

quoted

If you think about it as git and cogito being entirely separate projects,
where users would be expected to have the right version of git most of the
time (or ever), this is true. But I think that cogito is as closely tied
to git as the kernel is to kbuild or kconfig; the difference is that git
is not solely available with cogito, like kbuild is solely available with
the kernel.

I tend to disagree with you on this point. Cogito and Git share
arelationship more akin to xorg and gnome and this is something I think
Linus intended so that it would be very easy to build a layer on top of
the git toolset. Cogito is great and it fills a need but give it time
and other implementations and tool sets will come along that may
supersede it.

The point of this feature is to support other implementations and tool
sets. If there weren't other things using the git core, there would be no
reason to leave the current situation where cogito simply includes the
complete contents of git-pb. The relationship between cogito and git is,
however, not at all like that between Gnome and x.org; gnome could not be
started until X was essentially completely stable for several years (after
which X could be reimplemented and extended, so long as it retained the
same API). Cogito, on the other hand, is being developed concurrently with
git, and substantially informs git development. The current cogito doesn't
work completely correctly with any mainline git, whereas the current Gnome
works with every x.org release as well as any XFree86 or most other X
servers since the mid 90's.

Also, any particular user is probably only going to use one git-based
system, but will almost certainly use many different X clients.

	-Daniel
*This .sig left intentionally blank*

I've really got remember that reply to all option.
On Thu, 2005-05-12 at 15:46, Daniel Barkalow wrote:

On Thu, 12 May 2005, James Purser wrote:

quoted

On Thu, 2005-05-12 at 15:19, Daniel Barkalow wrote:

quoted

If you think about it as git and cogito being entirely separate

projects,

quoted

quoted

where users would be expected to have the right version of git

most of the

quoted

quoted

time (or ever), this is true. But I think that cogito is as

closely tied

quoted

quoted

to git as the kernel is to kbuild or kconfig; the difference is

that git

quoted

quoted

is not solely available with cogito, like kbuild is solely

available with

quoted

quoted

the kernel.

I tend to disagree with you on this point. Cogito and Git share
arelationship more akin to xorg and gnome and this is something I

think

quoted

Linus intended so that it would be very easy to build a layer on top

of

quoted

the git toolset. Cogito is great and it fills a need but give it

time

quoted

and other implementations and tool sets will come along that may
supersede it.

The point of this feature is to support other implementations and tool
sets. If there weren't other things using the git core, there would be

no

reason to leave the current situation where cogito simply includes the
complete contents of git-pb. The relationship between cogito and git

is,

however, not at all like that between Gnome and x.org; gnome could not

be

started until X was essentially completely stable for several years

(after

which X could be reimplemented and extended, so long as it retained

the

same API). Cogito, on the other hand, is being developed concurrently

with

git, and substantially informs git development. The current cogito

doesn't

work completely correctly with any mainline git, whereas the current

Gnome

works with every x.org release as well as any XFree86 or most other X
servers since the mid 90's.

Also, any particular user is probably only going to use one git-based
system, but will almost certainly use many different X clients.

      -Daniel
*This .sig left intentionally blank*

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Okay the gnome/xorg is a bad example the point I was trying to get
across was that cogito and git are not as intertwined as you say, if
development of cogito stopped tomorrow then git would keep going and
another second layer app would take its place.

Yes cogito helps with git development as it provides a great way to test
different situations in a different environment than you would normally
get by running the bare git tools your self.

The way I have been reading things (and I may be wrong about this, it
wouldn't be the first time :)) is that git is THE base line providing
the necessary tools and structure for anyone who wishes to build an
application on top. Cogito is an example of that second layer app, built
on top of the toolset and still able to talk to non cogito managed
trees. Sort of like CVS and its various client implentations (Command
Line, GCVS etc).

Again I may have gotten things arse about, if I have then I blame lack
of sleep :)
-- 
James Purser
http://ksit.dynalias.com