{"thread":{"id":"578","subject":"[RFC] Support projects including other projects","startedAt":"2005-05-12T04:23:40Z","lastAt":"2005-05-12T19:12:11Z","messageCount":14,"participants":["Daniel Barkalow","Junio C Hamano","James Purser","David Lang"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"3110","messageId":"Pine.LNX.4.21.0505112350420.30848-100000@iabervon.org","threadId":"578","inReplyTo":null,"subject":"[RFC] Support projects including other projects","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-05-12T04:23:40Z","receivedAt":"2005-05-12T04:23:40Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"I've come up with a way to handle projects like cogito which are based on\nother projects. I think that it actually solves the real problem with such\nprojects, and it is actually very simple.\n\nThe problem that such projects run into, especially while both the core\nand the non-core projects are in a state of substantial flux and when the \nnon-core developer(s) contribute needed changes to the core, is that the\ntwo projects not only have to be tracked, they have to be kept in \nsync. That is, a particular version of cogito requires a particular\nversion of git. There is a bit of convenience to having the tools\nmagically do the right thing when you check out the child project, but the\nthing that really requires tool support is that you need to be able to\nfind the version of git-pb which matches the version of cogito you're\ntrying to build (and you might be searching the history for where a bug\nwas introduced, so you may not be able to use the latest of either).\n\nThe solution is to add a header to commits: \"include {hash}\", which simply\nsays that the given hash, which is from the core project, is the commit\nneeded to build this commit of the non-core project. This comes from an\nargument to commit-tree (\"-I\", perhaps), and the parsing code needs to\nidentify the reference so that fsck-cache stays happy.\n\nGit doesn't do anything more; wrapping layers would be able to take care\nof the rest. When the wrapping layer determines that you are checking out\na commit with an include header, it also checks out the included commit,\nusing a different index file. The core treats everything as if you had a\nbunch of non-tracked files in the directory (those being the things in the\nother project). When you commit, it first commits any includes (if\nneeded), identifies the resulting core head, and passes that to the\ninclude for the final result.\n\nIt seems to me like this should work perfectly. The one weakness is that\nit's quite annoying to do by hand, since you have to simultaneously track\ntwo index files and remember to pass the argument to commit-tree each\ntime. (Also, it means that you'd ideally pull git-pb from the cogito\nrepository with a client that ignores things not reachable from your head,\nalthough Petr could still just copy and prune to match the current\nsituation).\n\nI've written up the git changes needed, if people are interested in the\npatch.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"3112","messageId":"7vk6m5kpue.fsf@assigned-by-dhcp.cox.net","threadId":"578","inReplyTo":"Pine.LNX.4.21.0505112350420.30848-100000@iabervon.org","subject":"Re: [RFC] Support projects including other projects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-12T04:52:57Z","receivedAt":"2005-05-12T04:52:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I think that the core of your idea of recording \"required\nversion\" of the depended project (core GIT) in the depending\nproject (Cogito) is a very sound one.  GNU Arch folks do\nsomething similar in their \"package-framework\" stuff.  \n\nI however do not think that belongs to the core GIT nor even to\nCogito for that matter.  To me, it feels like this is a pure\nbuild infrastructure issue.\n\nI think you could arrange something like that with today's core\nGIT tools, like this:\n\n - Tweak Cogito Makefile so that pure Cogito and core GIT are\n   housed in separate subdirectories;\n\n - Add \"required-git-pb\" file to Cogito source as a tracked\n   source file, and record the required version of git-pb there;\n\n - Arrange Cogito Makefile to make sure the subtree that has the\n   core GIT side meets \"required-git-pb\" constraints.  The\n   constraints could be \"at least contains this one\", \"exactly\n   this one\".  The policy would be differnt from a depending\n   project to another.  What happens if the requirements are not\n   met is also up to the policy of that depending project.\n\n"},{"id":"3113","messageId":"Pine.LNX.4.21.0505120057250.30848-100000@iabervon.org","threadId":"578","inReplyTo":"7vk6m5kpue.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Support projects including other projects","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-05-12T05:19:13Z","receivedAt":"2005-05-12T05:19:13Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 11 May 2005, Junio C Hamano wrote:\n\n> I think that the core of your idea of recording \"required\n> version\" of the depended project (core GIT) in the depending\n> project (Cogito) is a very sound one.  GNU Arch folks do\n> something similar in their \"package-framework\" stuff.  \n> \n> I however do not think that belongs to the core GIT nor even to\n> Cogito for that matter.  To me, it feels like this is a pure\n> build infrastructure issue.\n\nIf you think about it as git and cogito being entirely separate projects,\nwhere users would be expected to have the right version of git most of the\ntime (or ever), this is true. But I think that cogito is as closely tied\nto git as the kernel is to kbuild or kconfig; the difference is that git\nis not solely available with cogito, like kbuild is solely available with\nthe kernel.\n\n> I think you could arrange something like that with today's core\n> GIT tools, like this:\n> \n>  - Tweak Cogito Makefile so that pure Cogito and core GIT are\n>    housed in separate subdirectories;\n> \n>  - Add \"required-git-pb\" file to Cogito source as a tracked\n>    source file, and record the required version of git-pb there;\n> \n>  - Arrange Cogito Makefile to make sure the subtree that has the\n>    core GIT side meets \"required-git-pb\" constraints.  The\n>    constraints could be \"at least contains this one\", \"exactly\n>    this one\".  The policy would be differnt from a depending\n>    project to another.  What happens if the requirements are not\n>    met is also up to the policy of that depending project.\n\nWhen a particular cogito commit is made, it is impossible to tell whether\nthe next git-pb will work with it; the current set of patches could be\nrejected in mainline git, and different support for the same functionality\nadded which requires something different from cogito.\n\nThis also means that Petr can't really test changes to git before\ncommiting them (and a new cogito with the constraint changed), because the\ncogito build system would then require him to use a version he's not\ntesting.\n\nAlso, either the user has to keep track of two projects without any system\nsupport in the same directory structure and figure out how to follow the\ninstructions from the build system in getting the right version checked\nout in the right place, or the build system is tied to a particular\nwrapper layer.\n\nI think your idea is theoretically possible, but that it is just too\nimpractical for anyone to ever actually use it. It's something that people\ncould do with CVS (and it would actually work better, due to CVS's\nlimitations making the issues simpler), but people don't.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"3115","messageId":"7v8y2lknsp.fsf@assigned-by-dhcp.cox.net","threadId":"578","inReplyTo":"Pine.LNX.4.21.0505120057250.30848-100000@iabervon.org","subject":"Re: [RFC] Support projects including other projects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-12T05:37:10Z","receivedAt":"2005-05-12T05:37:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"DB\" == Daniel Barkalow <barkalow@iabervon.org> writes:\n\nDB> When a particular cogito commit is made, it is impossible to tell whether\nDB> the next git-pb will work with it; the current set of patches could be\nDB> rejected in mainline git, and different support for the same functionality\nDB> added which requires something different from cogito...\n\n ... Many problems with the approach of saying \"this Cogito\n     requires this git-pb\" omitted here; I agree that alone\n     may not solve problems ...\n\nDB> I think your idea is theoretically possible, but that it is just too\nDB> impractical...\n\nI do not think it is my idea.  Maybe I misunderstood what you\nmeant, but here is what you wrote in the message I responded to.\n\n    ... There is a bit of convenience to having the tools magically\n    do the right thing when you check out the child project, but the\n    thing that really requires tool support is that you need to be\n    able to find the version of git-pb which matches the version of\n    cogito you're trying to build (and you might be searching the\n    history for where a bug was introduced, so you may not be able\n    to use the latest of either).\n\nThat part is fine.  I already agreed that recording such version\ndependency would be a good thing.  I disagreed with the\n\"solution\", however, of having that recorded at the core level:\n\n    The solution is to add a header to commits: \"include {hash}\",\n    which simply says that the given hash, which is from the core\n    project, is the commit needed to build this commit of the\n    non-core project. This comes from an argument to commit-tree\n    (\"-I\", perhaps), and the parsing code needs to identify the\n    reference so that fsck-cache stays happy.\n\nI do not think the issues you are raising are solved by having\nthat \"include {hash}\" thing in the commit like you propose here,\ninstead of keeping it outside of the commit like I suggested.\n\nWhat I meant to say was just I do not think having this \"version\ndependency\" in the core or outside of the core would make any\ndifference.\n\n"},{"id":"3114","messageId":"1115876231.3085.4.camel@kryten","threadId":"578","inReplyTo":"Pine.LNX.4.21.0505120057250.30848-100000@iabervon.org","subject":"Re: [RFC] Support projects including other projects","fromName":"James Purser","fromEmail":"purserj@ksit.dynalias.com","sentAt":"2005-05-12T05:37:12Z","receivedAt":"2005-05-12T05:37:12Z","isPatch":false,"sender":{"key":"purserj@ksit.dynalias.com","avatar":null},"body":"On Thu, 2005-05-12 at 15:19, Daniel Barkalow wrote:\n> If you think about it as git and cogito being entirely separate projects,\n> where users would be expected to have the right version of git most of the\n> time (or ever), this is true. But I think that cogito is as closely tied\n> to git as the kernel is to kbuild or kconfig; the difference is that git\n> is not solely available with cogito, like kbuild is solely available with\n> the kernel.\nI tend to disagree with you on this point. Cogito and Git share\narelationship more akin to xorg and gnome and this is something I think\nLinus intended so that it would be very easy to build a layer on top of\nthe git toolset. Cogito is great and it fills a need but give it time\nand other implementations and tool sets will come along that may\nsupersede it.\n-- \nJames Purser\nhttp://ksit.dynalias.com\n\n"},{"id":"3116","messageId":"Pine.LNX.4.21.0505120137200.30848-100000@iabervon.org","threadId":"578","inReplyTo":"1115876231.3085.4.camel@kryten","subject":"Re: [RFC] Support projects including other projects","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-05-12T05:46:34Z","receivedAt":"2005-05-12T05:46:34Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 12 May 2005, James Purser wrote:\n\n> On Thu, 2005-05-12 at 15:19, Daniel Barkalow wrote:\n> > If you think about it as git and cogito being entirely separate projects,\n> > where users would be expected to have the right version of git most of the\n> > time (or ever), this is true. But I think that cogito is as closely tied\n> > to git as the kernel is to kbuild or kconfig; the difference is that git\n> > is not solely available with cogito, like kbuild is solely available with\n> > the kernel.\n> I tend to disagree with you on this point. Cogito and Git share\n> arelationship more akin to xorg and gnome and this is something I think\n> Linus intended so that it would be very easy to build a layer on top of\n> the git toolset. Cogito is great and it fills a need but give it time\n> and other implementations and tool sets will come along that may\n> supersede it.\n\nThe point of this feature is to support other implementations and tool\nsets. If there weren't other things using the git core, there would be no\nreason to leave the current situation where cogito simply includes the\ncomplete contents of git-pb. The relationship between cogito and git is,\nhowever, not at all like that between Gnome and x.org; gnome could not be\nstarted until X was essentially completely stable for several years (after\nwhich X could be reimplemented and extended, so long as it retained the\nsame API). Cogito, on the other hand, is being developed concurrently with\ngit, and substantially informs git development. The current cogito doesn't\nwork completely correctly with any mainline git, whereas the current Gnome\nworks with every x.org release as well as any XFree86 or most other X\nservers since the mid 90's.\n\nAlso, any particular user is probably only going to use one git-based\nsystem, but will almost certainly use many different X clients.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"3117","messageId":"Pine.LNX.4.21.0505120147100.30848-100000@iabervon.org","threadId":"578","inReplyTo":"7v8y2lknsp.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Support projects including other projects","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-05-12T06:04:43Z","receivedAt":"2005-05-12T06:04:43Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 11 May 2005, Junio C Hamano wrote:\n\n> I do not think the issues you are raising are solved by having\n> that \"include {hash}\" thing in the commit like you propose here,\n> instead of keeping it outside of the commit like I suggested.\n> \n> What I meant to say was just I do not think having this \"version\n> dependency\" in the core or outside of the core would make any\n> difference.\n\nI was primarily responding to your idea of it being outside the scope of\ncogito as well as outside the core.\n\nMy reasons for having it in the core are as follows:\n\n - All of the porcelain layers have to, at least, agree as to how this is\n   represented in order for repositories to be portable; since the\n   representation is common, it might as well be core.\n\n - There are currently no special files which are tracked for cogito (et \n   al) to put the information in.\n\n - Ideally, the dependancy would only be per-commit, not per-tree; if Petr\n   releases a new cogito which only merges a new mainline with the git-pb,\n   the cogito tree object should be the same (since the cogito content\n   didn't change). This means that it can't be anywhere other than the\n   commit.\n\n - If the solution to the issue of finding the necessary git-pb is to\n   store it with cogito, then the programs that pull from this repository\n   need to know that they need to pull the git-pb portion, and fsck-cache\n   needs to know that the cogito references the git-pb.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"3118","messageId":"7vvf5pj7is.fsf@assigned-by-dhcp.cox.net","threadId":"578","inReplyTo":"7v8y2lknsp.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Support projects including other projects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-12T06:14:03Z","receivedAt":"2005-05-12T06:14:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"JCH\" == Junio C Hamano <junkio@cox.net> writes:\n\nDaniel, I am sorry but I realize I completely misunderstood what\nyou meant by \"projects including other projects\".  What you are\ntrying to solve is the problem of feeding core GIT changes and\npure Cogito changes separately to the upstream _within_ _the_\n_current_ _source_ _tree_ _structure_ of Cogito, isn't it?\nThat's where your juggling index files and other complexity\ncomes from, and I did not realize that was what you were talking\nabout.  I should have realized it when you mentioned kbuild.\n\nWell, personally I do not think such project _overlays_ are\nworth supporting because it happens rarely, and to a certain\nextent it is simply an undisciplined way to organize the source\ntree.  Kbuild case may be justified, but I vaguely recall\nsomething very similar build infrastructure was used by busybox\nfolks---it could be using just their own copy of kbuild for that\nmatter.\n\nBut as you said in a separate message, I agree that core GIT\nlayer is meant to be independent from what Porcelain you put on\nit.  The relationship between Cogito and core GIT is not similar\nto kbuild and the kernel.  It is more like a random X11\napplication and Xlib.  Having them in the same source tree,\nintermixed, is less than optimal.\n\nI would not be surprised when future, if not the next, Cogito\nrelease has source tree organized more like JIT sources,\nshipping git-pb and cogito in separate directories, managed by\nseparate GIT_DIR.  That would make Pasky's life a lot simpler.\n\nAnd once the separation happens, the issue becomes just a simple\npackage version matching every distribution does (e.g. Debian's\nbinary package and library dependencies, or source Build-Depends\ndependencies), which is something already has been solved.\n\n"},{"id":"3119","messageId":"7v8y2lj6u9.fsf@assigned-by-dhcp.cox.net","threadId":"578","inReplyTo":"Pine.LNX.4.21.0505120147100.30848-100000@iabervon.org","subject":"Re: [RFC] Support projects including other projects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-12T06:28:46Z","receivedAt":"2005-05-12T06:28:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"DB\" == Daniel Barkalow <barkalow@iabervon.org> writes:\n\nDB> My reasons for having it in the core are as follows:\n\nDB>  - All of the porcelain layers have to, at least, agree as\nDB>  to how this is represented in order for repositories to be\nDB>  portable; since the representation is common, it might as\nDB>  well be core.\n\nThat is weak.  .git/refs/heads/master is not core, but something\nPorcelain need to agree on [*1*].\n\nDB>  - There are currently no special files which are tracked for cogito (et \nDB>    al) to put the information in.\n\nI am somewhat sympathetic to this, but then there are probably\nlot other things that are more relevant than this \"required\nversion\" thing.  One thing that immediately comes to mind is the\ndontdiff list.  Also, if you consider Cogito and GIT independent\nprojects as you said, you would probably need to have \"require\n{project-name} {commit-id}\", not \"include {commit-id}\".  Things\nstart smelling much more like the traditional package version\nmatching issue which is outside of SCM (let alone core GIT).\n\nDB>  - Ideally, the dependancy would only be per-commit, not\nDB>  per-tree; if Petr releases a new cogito which only merges a\nDB>  new mainline with the git-pb, the cogito tree object should\nDB>  be the same (since the cogito content didn't change). This\nDB>  means that it can't be anywhere other than the commit.\n\nAs I already said, I consider the current \"overlayed\" directory\nstructure broken and not worth considering the toolset support\n[*2*].\n\nDB>  - If the solution to the issue of finding the necessary\nDB>  git-pb is to store it with cogito, then the programs that\nDB>  pull from this repository need to know that they need to\nDB>  pull the git-pb portion, and fsck-cache needs to know that\nDB>  the cogito references the git-pb.\n\nI do not think this is necessary for the same reason as I\ndismissed the third point above.\n\n[Footnotes]\n\n*1* I consider git-pull-script one example of Porcelain, JIT\nknows about it as well.\n\n*2* \"Broken\" is probably a too strong word here.  I know Petr\ndid it that way because it was the simplest way to start, and I\nstarted the same way when I started JIT, until I realized\nseparating the core and treating the core as something I can\nborrow from the neighbouring directory is much easier to manage.\nI think Petr knows this, and I further think that is why he\nstarted git-pb.\n\n"},{"id":"3120","messageId":"1115879630.3085.40.camel@kryten","threadId":"578","inReplyTo":"Pine.LNX.4.21.0505120137200.30848-100000@iabervon.org","subject":"Re: [RFC] Support projects including other projects","fromName":"James Purser","fromEmail":"purserj@ksit.dynalias.com","sentAt":"2005-05-12T06:33:50Z","receivedAt":"2005-05-12T06:33:50Z","isPatch":false,"sender":{"key":"purserj@ksit.dynalias.com","avatar":null},"body":"I've really got remember that reply to all option.\nOn Thu, 2005-05-12 at 15:46, Daniel Barkalow wrote:\n> On Thu, 12 May 2005, James Purser wrote:\n> \n> > On Thu, 2005-05-12 at 15:19, Daniel Barkalow wrote:\n> > > If you think about it as git and cogito being entirely separate\nprojects,\n> > > where users would be expected to have the right version of git\nmost of the\n> > > time (or ever), this is true. But I think that cogito is as\nclosely tied\n> > > to git as the kernel is to kbuild or kconfig; the difference is\nthat git\n> > > is not solely available with cogito, like kbuild is solely\navailable with\n> > > the kernel.\n> > I tend to disagree with you on this point. Cogito and Git share\n> > arelationship more akin to xorg and gnome and this is something I\nthink\n> > Linus intended so that it would be very easy to build a layer on top\nof\n> > the git toolset. Cogito is great and it fills a need but give it\ntime\n> > and other implementations and tool sets will come along that may\n> > supersede it.\n> \n> The point of this feature is to support other implementations and tool\n> sets. If there weren't other things using the git core, there would be\nno\n> reason to leave the current situation where cogito simply includes the\n> complete contents of git-pb. The relationship between cogito and git\nis,\n> however, not at all like that between Gnome and x.org; gnome could not\nbe\n> started until X was essentially completely stable for several years\n(after\n> which X could be reimplemented and extended, so long as it retained\nthe\n> same API). Cogito, on the other hand, is being developed concurrently\nwith\n> git, and substantially informs git development. The current cogito\ndoesn't\n> work completely correctly with any mainline git, whereas the current\nGnome\n> works with every x.org release as well as any XFree86 or most other X\n> servers since the mid 90's.\n> \n> Also, any particular user is probably only going to use one git-based\n> system, but will almost certainly use many different X clients.\n> \n>       -Daniel\n> *This .sig left intentionally blank*\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\nOkay the gnome/xorg is a bad example the point I was trying to get\nacross was that cogito and git are not as intertwined as you say, if\ndevelopment of cogito stopped tomorrow then git would keep going and\nanother second layer app would take its place.\n\nYes cogito helps with git development as it provides a great way to test\ndifferent situations in a different environment than you would normally\nget by running the bare git tools your self.\n\nThe way I have been reading things (and I may be wrong about this, it\nwouldn't be the first time :)) is that git is THE base line providing\nthe necessary tools and structure for anyone who wishes to build an\napplication on top. Cogito is an example of that second layer app, built\non top of the toolset and still able to talk to non cogito managed\ntrees. Sort of like CVS and its various client implentations (Command\nLine, GCVS etc).\n\nAgain I may have gotten things arse about, if I have then I blame lack\nof sleep :)\n-- \nJames Purser\nhttp://ksit.dynalias.com\n\n"},{"id":"3165","messageId":"Pine.LNX.4.21.0505121218280.30848-100000@iabervon.org","threadId":"578","inReplyTo":"7v8y2lj6u9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Support projects including other projects","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-05-12T16:51:29Z","receivedAt":"2005-05-12T16:51:29Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 11 May 2005, Junio C Hamano wrote:\n\n> >>>>> \"DB\" == Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> DB> My reasons for having it in the core are as follows:\n> \n> DB>  - All of the porcelain layers have to, at least, agree as\n> DB>  to how this is represented in order for repositories to be\n> DB>  portable; since the representation is common, it might as\n> DB>  well be core.\n> \n> That is weak.  .git/refs/heads/master is not core, but something\n> Porcelain need to agree on [*1*].\n\nI think it is a defect of the current core that it fails to completely\nspecify a portable repository format. Obviously, it is not necessary to\nhave things in the core for this reason, but it's also not necessary to\nhave anything at all in the core. We could eliminate commits entirely in\nfavor of putting the information in special files in trees, and it would\nstill be as complete as it is, although it would also be unmaintainable.\n\n> DB>  - There are currently no special files which are tracked for cogito (et \n> DB>    al) to put the information in.\n> \n> I am somewhat sympathetic to this, but then there are probably\n> lot other things that are more relevant than this \"required\n> version\" thing.  One thing that immediately comes to mind is the\n> dontdiff list.\n\nThe dontdiff list isn't expected to change with every commit, however.\n\n> Also, if you consider Cogito and GIT independent projects as you said,\n> you would probably need to have \"require {project-name} {commit-id}\",\n> not \"include {commit-id}\".\n\nI *don't* consider Cogito and GIT to be independant projects. GIT is\nindependant of Cogito, but Cogito includes GIT as part of it.\n\nIf you don't like the structure of Cogito, I have a set of projects at\nwork, where I have a bunch of microcontroller programs and a library of\ncommon code. Traditionally, there are two possible arrangements: either\nthey are all separate projects, in which case the user has to figure out\nwhat versions match, or they are the same project, in which case everybody\nhas to get everything. What I would like is to have the library consider\nitself a separate project, but each program consider itself, in some\nsense, the same project as the library (but not as other programs).\n\n> Things start smelling much more like the traditional package version \n> matching issue which is outside of SCM (let alone core GIT).\n\nOnce the core portion matures to the point where it gets used without\nprogram-specific patches, it can be done outside of SCM. But it doesn't\nmake sense to have an SCM require that the projects are really mature in\norder to work well, since active development is supposed to be what an SCM\nis for.\n\n> DB>  - Ideally, the dependancy would only be per-commit, not\n> DB>  per-tree; if Petr releases a new cogito which only merges a\n> DB>  new mainline with the git-pb, the cogito tree object should\n> DB>  be the same (since the cogito content didn't change). This\n> DB>  means that it can't be anywhere other than the commit.\n> \n> As I already said, I consider the current \"overlayed\" directory\n> structure broken and not worth considering the toolset support\n\nYou missed my point here entirely. I think that the cogito tree including\nany non-source files in it (if there are such) should be the same. So the\ndependancy can't be tracked in the tree.\n\n> DB>  - If the solution to the issue of finding the necessary\n> DB>  git-pb is to store it with cogito, then the programs that\n> DB>  pull from this repository need to know that they need to\n> DB>  pull the git-pb portion, and fsck-cache needs to know that\n> DB>  the cogito references the git-pb.\n> \n> I do not think this is necessary for the same reason as I\n> dismissed the third point above.\n\nDo you have some solution to the problem of having the porcelain\nlayer (or the end user) find the version of git that a version of cogito\nneeds, in some way such that if I'm working on the project and make a\nchange to cogito and a matching change to git, Petr can get them.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"3169","messageId":"Pine.LNX.4.62.0505121006150.25177@qynat.qvtvafvgr.pbz","threadId":"578","inReplyTo":"Pine.LNX.4.21.0505121218280.30848-100000@iabervon.org","subject":"Re: [RFC] Support projects including other projects","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2005-05-12T17:24:42Z","receivedAt":"2005-05-12T17:24:42Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"I was thinking about this recently while reading an article on bittorrent \nand how it works and it occured to me that perhapse the network access \nmodel of git should be reexamined.\n\ngit produces a large pool of objects, there are two ways that people want \nto access these objects.\n\n1. pull the current version of a project (either a straight 'ckeckout' \ntype pull or a 'merge' to a local project)\n\n2. pull the objects nessasary for past versions of a project (either all \nthe way back to the beginning of time or back to some point, that point \nbeing a number of possibilities (date, version, things you don't have, \netc)\n\nin either case the important thing that's key are the indexes related to a \nparticular project, the objects themselves could all be in one huge pool \nfor all projects that ever existed (this doesn't make sense if you use \nrsync to copy repositories as Linux origionally did, but if you have a \nmore git-aware transport it can make sense)\n\nI believe that there are going to be quite a number of cases where the \nsame object is used for multiple projects (either becouse the project is a \nfork of another project or becouse some functions (or include files) are \nso trivial that they are basicly boilerplate and get reused or recreated) \nif you think about a major mirror server distributing a dozen linux \ndistros via git you will realize that in many cases the source files, \nscripts, and (in many cases) even the binaries are really going to be \nidentical objects for all the distros so a ftp/http server that used a git \nfilesystem could result in a pretty significant saveings in disk space.\n\nIn addition, when you are doing a pull you can accept data from \nnon-authoritative sources since each object (and it's index info) includes \nenough info to validate the object hasn't been tampered with (at least \nuntil such time as the hashes are sufficiantly broken, but that's another \ndebate, and we had that one :-). so a bittorrent-like peer sharing system \nto fetch objects identified by the index files would open the potential \nfor saving significant bandwith on the master servers while not \ncomprimising the trees at all.\n\nGoing back (somewhat) to the subject at hand, with something like this you \nshould be able to combine as many projects as you want in one repository, \nand the only issue would be the work nessasary to go through that \nrepository and all the index files that point at it when you want to prune \nold data out of the object pool to save disk space.\n\nthoughts? unfortunnatly I don't have the time to even consider codeing \nsomething like this up, but hopefully it will spark interest for someone \nwho does.\n\nDavid Lang\n\n-- \nThere are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.\n  -- C.A.R. Hoare\n"},{"id":"3173","messageId":"7vll6kgu21.fsf@assigned-by-dhcp.cox.net","threadId":"578","inReplyTo":"Pine.LNX.4.21.0505121218280.30848-100000@iabervon.org","subject":"Re: [RFC] Support projects including other projects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-12T18:47:50Z","receivedAt":"2005-05-12T18:47:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"DB\" == Daniel Barkalow <barkalow@iabervon.org> writes:\n\nDB> Do you have some solution to the problem of having the\nDB> porcelain layer (or the end user) find the version of git\nDB> that a version of cogito needs, in some way such that if I'm\nDB> working on the project and make a change to cogito and a\nDB> matching change to git, Petr can get them.\n\nI have to think about this a bit but let me understand the\nproblem first.  Let's say it is a couple of weeks ago when there\nwere not cg-status.  You write cg-status, by adding -t flag to\nls-files.c  You commit the addition of -t flag to git-pb\nrepository and note the commit id.  You then commit addition of\ncg-status to cogito repository and when you do so you want the\nparty that pulls the latter commit to know it needs the former\ncommit in the git-pb tree.  Is it what you are solving here?\n\n\n"},{"id":"3176","messageId":"Pine.LNX.4.21.0505121449370.30848-100000@iabervon.org","threadId":"578","inReplyTo":"7vll6kgu21.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Support projects including other projects","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-05-12T19:12:11Z","receivedAt":"2005-05-12T19:12:11Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 12 May 2005, Junio C Hamano wrote:\n\n> I have to think about this a bit but let me understand the\n> problem first.  Let's say it is a couple of weeks ago when there\n> were not cg-status.  You write cg-status, by adding -t flag to\n> ls-files.c  You commit the addition of -t flag to git-pb\n> repository and note the commit id.  You then commit addition of\n> cg-status to cogito repository and when you do so you want the\n> party that pulls the latter commit to know it needs the former\n> commit in the git-pb tree.  Is it what you are solving here?\n\nRight; and I'm not Petr, so the place that has the -t flag in ls-files\nisn't his git-pb repository, and I'm not going to remember to tell him\nabout two places to pull from or two heads to pull.\n\nProbably my biggest concern here is that it has to not make anything more\ndifficult for Cogito hackers (or people working on similarly arranged\nprojects) to have the other project demarcated as separate, or they'd tend\nto be lazy and the upstream core will suffer. I believe that this is why\npeople in practice tend not to bother making projects clean and modular\nwith current tools. Having it streamlined and automatic would mean that\npeople in the position that Petr was in when he started would do it by\ndefault.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"}]}