{"thread":{"id":"557","subject":"[RFD] Overlapping projects","startedAt":"2005-05-10T04:56:33Z","lastAt":"2005-05-10T12:04:54Z","messageCount":5,"participants":["Daniel Barkalow","Junio C Hamano","Sean"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"2951","messageId":"Pine.LNX.4.21.0505100040320.30848-100000@iabervon.org","threadId":"557","inReplyTo":null,"subject":"[RFD] Overlapping projects","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-05-10T04:56:33Z","receivedAt":"2005-05-10T04:56:33Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"It seems to me like projects like cogito which are based on a core which\nis itself a project and which is also part of other projects would benefit\nfrom some sort of support.\n\nIn particular, it would be nice if Linus could pull the changes to the\ncore without getting the wrapper programs at all.\n\nI'm thinking something like having a head for cogito and a head for git in\nthe same repository, where the trees for git only have the core files, and\nthe commits for cogito have, in addition to a tree with only the\ncogito-specific files, a reference to a git commit that they include.\n\nIt seems to me like this area contains a brilliant idea that I haven't\nhad so far, and maybe someone can come up with it.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"2953","messageId":"7v8y2nsl38.fsf@assigned-by-dhcp.cox.net","threadId":"557","inReplyTo":"Pine.LNX.4.21.0505100040320.30848-100000@iabervon.org","subject":"Re: [RFD] Overlapping projects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-10T05:31:39Z","receivedAt":"2005-05-10T05:31:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"DB\" == Daniel Barkalow writes:\n\nDB> It seems to me like projects like cogito which are based on a core which\nDB> is itself a project and which is also part of other projects would benefit\nDB> from some sort of support.\n\nI personally feel supporting that kind of development directory\nstructure is backwards, and Cogito is a very bad example for it.\n\nThings could have been structured in such a way to have Cogito\nand core GIT in separate directories hanging from the top level,\nand Cogito can borrow pieces of GIT from the neighboring\ndirectory if it needed to build specialized binary using\nlibgit.a. Unless Petr makes changes to core GIT that is _too_\nspecific for general use (read: does not meet Linus' taste), we\nshould be able to port the nicer changes made to the core GIT\nfor Cogito's use (like git-ls-files \"-t\" flag) back to core GIT\nand there would not be a reason for Cogito to keep carrying its\nown copy of modified core GIT.\n\nDB> In particular, it would be nice if Linus could pull the\nDB> changes to the core without getting the wrapper programs at\nDB> all.\n\nYes, that is a very desirable arrangement.\n\nHowever, that does not require to keep them in the same\nrepository. Cogito _could_ have been shipped this way:\n\n + (top-level)\n / \\\n cg git\n (Cogito sources) (copy of core GIT files)\n .git/ for Cogito .git/ for core GIT\n only\n\nwith an instruction like:\n\n The tarball contains cg and git subdirectories. cg part\n implements Cogito, and git part is a copy of recent if not\n latest core GIT. Go to cg and type \"make\" to build both of\n them. Theoretically they can be independently updated to\n the latest but preferred combination is to use at least this\n release of core GIT to use this version of Cogito ...\n\nMaybe I am being too idealistic. I do not deny there are people\nwho want to manage \"projects within projects\" structure and\nother people like CVS, subversion and arch do support that\nstyle. My impression about them is that the way CVS does it via\nCVSROOT/modules looked like an ugly hack bolted onto it as an\nafterthought, external stuff subversion uses did not feel quite\nright (although nicer than what CVS does), and what arch does\nwas more reasonable but the boundary between SCM and build\nenvironment was quite blurry there. And many people \"wanting to\ndo so\" and other people \"supporting doing it\" do not necessarily\nmake that right.\n\n"},{"id":"2955","messageId":"Pine.LNX.4.21.0505100135110.30848-100000@iabervon.org","threadId":"557","inReplyTo":"7v8y2nsl38.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] Overlapping projects","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-05-10T05:51:01Z","receivedAt":"2005-05-10T05:51:01Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 9 May 2005, Junio C Hamano wrote:\n\n> >>>>> \"DB\" == Daniel Barkalow writes:\n> \n> DB> It seems to me like projects like cogito which are based on a core which\n> DB> is itself a project and which is also part of other projects would benefit\n> DB> from some sort of support.\n> \n> I personally feel supporting that kind of development directory\n> structure is backwards, and Cogito is a very bad example for it.\n\nThe directory structure is definitely awkward. I'd personally put cogito\nstuff in a separate directory. But that's a matter of which paths belong\nto which commit.\n\n> Things could have been structured in such a way to have Cogito\n> and core GIT in separate directories hanging from the top level,\n> and Cogito can borrow pieces of GIT from the neighboring\n> directory if it needed to build specialized binary using\n> libgit.a. Unless Petr makes changes to core GIT that is _too_\n> specific for general use (read: does not meet Linus' taste), we\n> should be able to port the nicer changes made to the core GIT\n> for Cogito's use (like git-ls-files \"-t\" flag) back to core GIT\n> and there would not be a reason for Cogito to keep carrying its\n> own copy of modified core GIT.\n> \n> DB> In particular, it would be nice if Linus could pull the\n> DB> changes to the core without getting the wrapper programs at\n> DB> all.\n> \n> Yes, that is a very desirable arrangement.\n> \n> However, that does not require to keep them in the same\n> repository. Cogito _could_ have been shipped this way:\n> \n> + (top-level)\n> / \\\n> cg git\n> (Cogito sources) (copy of core GIT files)\n> .git/ for Cogito .git/ for core GIT\n> only\n> \n> with an instruction like:\n> \n> The tarball contains cg and git subdirectories. cg part\n> implements Cogito, and git part is a copy of recent if not\n> latest core GIT. Go to cg and type \"make\" to build both of\n> them. Theoretically they can be independently updated to\n> the latest but preferred combination is to use at least this\n> release of core GIT to use this version of Cogito ...\n\nBut when Petr adds something to the core, intended for eventual inclusion\nin the mainline, and uses it in cogito, this breaks everything, because\nthen people have to know to pull both the latest cogito and the latest git\nfrom him. If the new git isn't backwards-compatible, then someone building\nan old cogito would have to somehow find the matching old git.\n\nThis is far worse than just including git and sending Linus patches; the\nonly way to make this manageable would be to suspend cogito until git was\ncompletely finished.\n\nThe important thing, I think, is being able to connect a Cogito with the\ngit it uses, while both are unstable and under active development. It\nwould be nice to be able to have the obvious things happen when you pull\nthe latest cogito and check it out, and when you commit with changes to\nfiles from each of them, but that's less important.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"2956","messageId":"7vhdhbr4ac.fsf@assigned-by-dhcp.cox.net","threadId":"557","inReplyTo":"Pine.LNX.4.21.0505100135110.30848-100000@iabervon.org","subject":"Re: [RFD] Overlapping projects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-10T06:19:55Z","receivedAt":"2005-05-10T06:19:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"DB\" == Daniel Barkalow writes:\n\n>> ...\n>> with an instruction like:\n>> \n>> ... Theoretically they can be independently updated to\n>> the latest but preferred combination is to use at least this\n>> release of core GIT to use this version of Cogito ...\n\nDB> But when Petr adds something to the core, intended for eventual inclusion\nDB> in the mainline, and uses it in cogito, this breaks everything, because\nDB> then people have to know to pull both the latest cogito and the latest git\nDB> from him. If the new git isn't backwards-compatible, then someone building\nDB> an old cogito would have to somehow find the matching old git.\n\nI think we are in agreement and saying the same thing. Yes, if\npeople wants to do mix and match, they should know what they are\ndoing.\n\nAlso I do not see any reason not to have GIT that comes from\nCogito additional stuff while Linus tree lags behind, which in a\nsense already has been the case for some commands. Separating\ndirectories would make things easier to manage, not harder.\n\nAnyhow let's wait and see what Petr does. He said he has been\npreparing core backports earlier. No point arguing about his\ntree without helping him.\n\n"},{"id":"2972","messageId":"4385.10.10.10.24.1115726694.squirrel@linux1","threadId":"557","inReplyTo":"Pine.LNX.4.21.0505100040320.30848-100000@iabervon.org","subject":"Re: [RFD] Overlapping projects","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2005-05-10T12:04:54Z","receivedAt":"2005-05-10T12:04:54Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, May 10, 2005 12:56 am, Daniel Barkalow said:\n> It seems to me like projects like cogito which are based on a core which\n> is itself a project and which is also part of other projects would benefit\n> from some sort of support.\n>\n> In particular, it would be nice if Linus could pull the changes to the\n> core without getting the wrapper programs at all.\n>\n> I'm thinking something like having a head for cogito and a head for git in\n> the same repository, where the trees for git only have the core files, and\n> the commits for cogito have, in addition to a tree with only the\n> cogito-specific files, a reference to a git commit that they include.\n>\n> It seems to me like this area contains a brilliant idea that I haven't\n> had so far, and maybe someone can come up with it.\n>\n\nThat sounds like a great idea and shouldn't need any brilliant ideas to\nimplement. Just need to push a little more multi-head handling down into \n git. The Cogito build process could then include a checkout of the\ngit-core branch. Would be much cleaner than the way it is handled now.\n\nSean\n\n\n"}]}