{"thread":{"id":"23671","subject":"RFD: a submodule-like facility that tracks branches rather than commits","startedAt":"2010-05-02T11:02:58Z","lastAt":"2010-05-03T02:05:04Z","messageCount":5,"participants":["Jon Seymour","Junio C Hamano","Dmitrijs Ledkovs"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140756","messageId":"w2n2cfc40321005020402gdc210b79v2652afa849cf7a60@mail.gmail.com","threadId":"23671","inReplyTo":null,"subject":"RFD: a submodule-like facility that tracks branches rather than commits","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-05-02T11:02:58Z","receivedAt":"2010-05-02T11:02:58Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"Has consideration ever been given to a submodule-like facility where\nthe configuration information maintained in the supermodule for the\nsubmodule is not a gitlink but is instead the name of a branch (or\ngenerally, a symbolic reference within the nested submodule).\n\nIn this case, \"git submodule update\" would checkout the specified\nbranch of each submodule rather than the specified commit.\n\nOf course, the intent of such a facility would be to allow git\nsupermodules to be used to simplify management of a group of related,\nyet indOfependent, git projects.\n\njon.\n"},{"id":"140782","messageId":"7veihuuwdj.fsf@alter.siamese.dyndns.org","threadId":"23671","inReplyTo":"w2n2cfc40321005020402gdc210b79v2652afa849cf7a60@mail.gmail.com","subject":"Re: RFD: a submodule-like facility that tracks branches rather than commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-02T16:00:24Z","receivedAt":"2010-05-02T16:00:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Seymour writes:\n\n> Has consideration ever been given to a submodule-like facility where\n> the configuration information maintained in the supermodule for the\n> submodule is not a gitlink but is instead the name of a branch (or\n> generally, a symbolic reference within the nested submodule).\n\nI think this comes up from time to time, and there was an even a slightly\nmore concrete suggestion to us 0{40} in the tree object to denote such an\nentry.\n\nBut once people realize that there is no single canonical authoritative\nrepository whose branch heads point at the same commits for everybody in a\ndistributed environment, the line of thought to touch gitlink entries gets\nretracted or discarded as a misguided idea.\n\nI however don't think it would hurt to enrich .gitmodules with not just\nthe repository information but with branch information to help clones\ndecide which commit (other than what is recorded in the tree of the\nsuperproject's commit) on the named remote tracking branch to try out with\nthe superproject's commit.\n"},{"id":"140783","messageId":"q2j86ecb3c71005020904kf543e987s19cd396ef672bd79@mail.gmail.com","threadId":"23671","inReplyTo":"7veihuuwdj.fsf@alter.siamese.dyndns.org","subject":"Re: RFD: a submodule-like facility that tracks branches rather than commits","fromName":"Dmitrijs Ledkovs","fromEmail":"dmitrij.ledkov@ubuntu.com","sentAt":"2010-05-02T16:04:35Z","receivedAt":"2010-05-02T16:04:35Z","isPatch":false,"sender":{"key":"dmitrij.ledkov@ubuntu.com","avatar":"https://gravatar.com/avatar/79b618c6eb391ddb486c2ee0d3b429014e0e9ba579fd55f2e035f482fc8c24f4?d=mp&s=160"},"body":"On 2 May 2010 17:00, Junio C Hamano wrote:\n> Jon Seymour writes:\n>\n>> Has consideration ever been given to a submodule-like facility where\n>> the configuration information maintained in the supermodule for the\n>> submodule is not a gitlink but is instead the name of a branch (or\n>> generally, a symbolic reference within the nested submodule).\n>\n> I think this comes up from time to time, and there was an even a slightly\n> more concrete suggestion to us 0{40} in the tree object to denote such an\n> entry.\n>\n> But once people realize that there is no single canonical authoritative\n> repository whose branch heads point at the same commits for everybody in a\n> distributed environment, the line of thought to touch gitlink entries gets\n> retracted or discarded as a misguided idea.\n>\n> I however don't think it would hurt to enrich .gitmodules with not just\n> the repository information but with branch information to help clones\n> decide which commit (other than what is recorded in the tree of the\n> superproject's commit) on the named remote tracking branch to try out with\n> the superproject's commit.\n>\n\n\nGnome uses jhbuild to build out of git, tarballs and other vcs's. It\nhas quite a bit of code of recursivly finding & updating all\nsubmodules to the latest tip.\n\nThis is want you generally want when you integrate.\n\nWhen you actually want to lock on a particular revision and not track\nupstream branches I believe subtree merge strategy should be used\ninstead of submodules.\n\nI beleive you should be able to specify symbolic references for the\ngit submodule to store.\n"},{"id":"140798","messageId":"l2u2cfc40321005021539v573e58a5j15696d81b5e5acd5@mail.gmail.com","threadId":"23671","inReplyTo":"7veihuuwdj.fsf@alter.siamese.dyndns.org","subject":"Re: RFD: a submodule-like facility that tracks branches rather than commits","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-05-02T22:39:42Z","receivedAt":"2010-05-02T22:39:42Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Mon, May 3, 2010 at 2:00 AM, Junio C Hamano wrote:\n> Jon Seymour writes:\n>\n>> Has consideration ever been given to a submodule-like facility where\n>> the configuration information maintained in the supermodule for the\n>> submodule is not a gitlink but is instead the name of a branch (or\n>> generally, a symbolic reference within the nested submodule).\n>\n> I think this comes up from time to time, and there was an even a slightly\n> more concrete suggestion to us 0{40} in the tree object to denote such an\n> entry.\n>\n> But once people realize that there is no single canonical authoritative\n> repository whose branch heads point at the same commits for everybody in a\n> distributed environment, the line of thought to touch gitlink entries gets\n> retracted or discarded as a misguided idea.\n>\n\nI understand the point about there being no canonical authority,\nparticularly in a truly distributed environment - any use of branches\nwould have to imply that users followed some convention when\npublishing the entire set.\n\nOn the other hand, there is actually precedent for use of convention\nlike that in the submodule facility - the use of relative paths to\ndescribe the relative locations of submodule repos only really works\nif everyone who publishes the supermodule uses the filesystem\nstructure for the directories containing the super- and sub-module\nrepos.\n\n> I however don't think it would hurt to enrich .gitmodules with not just\n> the repository information but with branch information to help clones\n> decide which commit (other than what is recorded in the tree of the\n> superproject's commit) on the named remote tracking branch to try out with\n> the superproject's commit.\n>\n>\n\nI can see that this could work. Presumably git submodule sync would be\nmodified in this case to help switch branches.\n\nAlso needed, I think, would be a way to sync the .gitmodule file with\nthe current submodule branch assignments.\n\nI guess there is no reason why I cannot prototype a facility of this\nkind with a local helper script. If I it ends up being useful, I'll\nconsider posting a patch.\n\njon.\n"},{"id":"140807","messageId":"7vsk69u4dr.fsf@alter.siamese.dyndns.org","threadId":"23671","inReplyTo":"l2u2cfc40321005021539v573e58a5j15696d81b5e5acd5@mail.gmail.com","subject":"Re: RFD: a submodule-like facility that tracks branches rather than commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-03T02:05:04Z","receivedAt":"2010-05-03T02:05:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Seymour writes:\n\n>> But once people realize that there is no single canonical authoritative\n>> repository whose branch heads point at the same commits for everybody in a\n>> distributed environment, the line of thought to touch gitlink entries gets\n>> retracted or discarded as a misguided idea.\n>>\n>\n> I understand the point about there being no canonical authority,\n> particularly in a truly distributed environment - any use of branches\n> would have to imply that users followed some convention when\n> publishing the entire set.\n>\n> On the other hand, there is actually precedent for use of convention\n> like that in the submodule facility - the use of relative paths to\n> describe the relative locations of submodule repos only really works\n> if everyone who publishes the supermodule uses the filesystem\n> structure for the directories containing the super- and sub-module\n> repos.\n\nThat's not exactly what I meant.\n\nIf the superproject commit didn't record the exact commit for each\nsubmodule, and only said \"the tip of branch X\" (presumably \"as of this\nwriting\"), then there is no way to reliably reproduce the build product\ngiven the superproject commit alone.\n\n>> I however don't think it would hurt to enrich .gitmodules with not just\n>> the repository information but with branch information to help clones\n>> decide which commit (other than what is recorded in the tree of the\n>> superproject's commit) on the named remote tracking branch to try out with\n>> the superproject's commit.\n>\n> I can see that this could work. Presumably git submodule sync would be\n> modified in this case to help switch branches.\n\nThere are two ways to use submodules. As I said already, the superproject\ncommit records exact commit for each submodule by design, to ensure that\nthe exact state including submodules can be reproduced. You manage\nsubmodules as separate projects, and the top level superproject commit\npicks a _good_ commit suitable for the purpose of the superproject, not\njust a random one that happens to be at the tip for a given day, to use\nfrom the submodule.\n\nBut it is not implausible for the top level maintainer of thesuperproject\nof a project not to even care about what s/he is shipping exactly, and\ninstead wish to describe \"under this top level directory, check out these\nprojects my colleagues have as subdirectories\" and nothing else. In such\na case, the exact commit for each submodule recorded in the superproject\nstill can be used to reproduce the exact state if the top level maintainer\ncared, but you can instead _choose to ignore_ that information and check\nout the random commit that happen to be at the tip of the named branch.\nIt could appear that such a use pattern is abusing the submodule support\nmerely to implement a glorified ftp, but in a project that is run that\nway, everybody understands and agrees that the commit object recorded in\nthe superproject is meaningless, so there is no harm done.\n\n> I guess there is no reason why I cannot prototype a facility of this\n> kind with a local helper script. If I it ends up being useful, I'll\n> consider posting a patch.\n\nYes, that's the spirit ;-)\n"}]}