{"thread":{"id":"57873","subject":"Git Submodules ref setting","startedAt":"2022-05-12T20:02:01Z","lastAt":"2022-05-13T15:23:04Z","messageCount":5,"participants":["Вадим Цветков","Philip Oakley","Philippe Blain","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"455215","messageId":"F20FCD5B-7788-4D4C-8402-2C4CF447B2F5@gmail.com","threadId":"57873","inReplyTo":null,"subject":"Git Submodules ref setting","fromName":"Вадим Цветков","fromEmail":"vadim.tsvetkov80@gmail.com","sentAt":"2022-05-12T20:01:53Z","receivedAt":"2022-05-12T20:02:01Z","isPatch":false,"sender":{"key":"vadim.tsvetkov80@gmail.com","avatar":null},"body":"Hello,\n\nI've started a small project which involves several git repositories, which depends on each other.\nFor dealing with these repos I wanted to use git submodules as a simple package manager.\nHowever, it seems impossible to lock a submodule to particular ref, only to a branch.\nI would like to ask if this is deliberate design choice?\nAnd if it's not, may I contribute this feature?"},{"id":"455218","messageId":"c9097f6d-3bae-a5ee-96e5-1760bb51112c@iee.email","threadId":"57873","inReplyTo":"F20FCD5B-7788-4D4C-8402-2C4CF447B2F5@gmail.com","subject":"Re: Git Submodules ref setting","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-05-12T21:18:55Z","receivedAt":"2022-05-12T21:19:10Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 12/05/2022 21:01, Вадим Цветков wrote:\n> Hello,\n>\n> I've started a small project which involves several git repositories, which depends on each other.\n> For dealing with these repos I wanted to use git submodules as a simple package manager.\n> However, it seems impossible to lock a submodule to particular ref, only to a branch.\n> I would like to ask if this is deliberate design choice?\n\nThis may be a confusion about how some large projects use sub-modules \nand are now able to follow the developments within a sub-module branch.\n\nThe original sub-module mechanism is still available where the \nsub-module is locked at a specific commit object id's hash i.e. a \nspecific 'library' version of that sub-module (in that context assumed \nto be rarely changing).\n> And if it's not, may I contribute this feature?\n--\nPhilip\n"},{"id":"455233","messageId":"88fa7138-cb3f-ab88-525c-198396b0a262@gmail.com","threadId":"57873","inReplyTo":"F20FCD5B-7788-4D4C-8402-2C4CF447B2F5@gmail.com","subject":"Re: Git Submodules ref setting","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2022-05-12T22:42:09Z","receivedAt":"2022-05-12T22:42:16Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi, \n\nLe 2022-05-12 à 16:01, Вадим Цветков a écrit :\n> Hello,\n> \n> I've started a small project which involves several git repositories, which depends on each other.\n> For dealing with these repos I wanted to use git submodules as a simple package manager.\n> However, it seems impossible to lock a submodule to particular ref, only to a branch.\n\nSubmodules are recorded in the superproject *at a specific commit*.\nThat's the data model. There is no other options.\n\nThere is a 'branch' setting that you can put in '.gitmodules'.\nThis *only* affects the command 'git submodule update --remote', nothing else.\n\nIf you mean that you would like to have a non-branch ref recorded in '.gitmodules'\ni.e. something like refs/other-refs/example instead of 'some-branch' that corresponds\nto 'refs/heads/some-branch', then no this is not possible either.\n\n> I would like to ask if this is deliberate design choice?\n\nYes, it was a deliberate design choice to have a deterministic state\nof a repository using submodules upon 'git clone'. Recording a submodule\nat a specific branch instead of at a specific commit would make this design\nchoice impossible to achieve.\n\n> And if it's not, may I contribute this feature?\n> \n\nIt depends on what you mean by 'lock submodule to a specific ref'.\n\nI encourage you to read the \"Git Submodules\" chapter of the Pro Git book [1]\nfor an in-depth overview of how submodules work. And after that, for reference\nthe Git documentation:\n\n- git-submodule(1): https://git-scm.com/docs/git-submodule\n- gitsubmodules(7): https://git-scm.com/docs/gitsubmodules\n- gitmodules(5): https://git-scm.com/docs/gitmodules\n\nI hope that helps,\n\nPhilippe.\n\n[1] https://git-scm.com/book/en/v2/Git-Tools-Submodules\n"},{"id":"455259","messageId":"9a01bede-40d8-e7e8-6d8c-42beea8f6f35@iee.email","threadId":"57873","inReplyTo":"88fa7138-cb3f-ab88-525c-198396b0a262@gmail.com","subject":"Re: Git Submodules ref setting","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-05-13T08:46:17Z","receivedAt":"2022-05-13T08:46:28Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 12/05/2022 23:42, Philippe Blain wrote:\n> Hi,\n>\n> Le 2022-05-12 à 16:01, Вадим Цветков a écrit :\n>> Hello,\n>>\n>> I've started a small project which involves several git repositories, which depends on each other.\n>> For dealing with these repos I wanted to use git submodules as a simple package manager.\n>> However, it seems impossible to lock a submodule to particular ref, only to a branch.\n> Submodules are recorded in the superproject *at a specific commit*.\n> That's the data model. There is no other options.\n>\n> There is a 'branch' setting that you can put in '.gitmodules'.\n> This *only* affects the command 'git submodule update --remote', nothing else.\n>\n> If you mean that you would like to have a non-branch ref recorded in '.gitmodules'\n> i.e. something like refs/other-refs/example instead of 'some-branch' that corresponds\n> to 'refs/heads/some-branch', then no this is not possible either.\n>\n>> I would like to ask if this is deliberate design choice?\n> Yes, it was a deliberate design choice to have a deterministic state\n> of a repository using submodules upon 'git clone'. Recording a submodule\n> at a specific branch instead of at a specific commit would make this design\n> choice impossible to achieve.\n>\n>> And if it's not, may I contribute this feature?\n>>\n> It depends on what you mean by 'lock submodule to a specific ref'.\n>\n> I encourage you to read the \"Git Submodules\" chapter of the Pro Git book [1]\n> for an in-depth overview of how submodules work. And after that, for reference\n> the Git documentation:\n\nI didn't find the man page, or the scm chapter that great in explaining \nthe overall way that sub-modules are conceived and organised.\n\nThere is an implicit assumption in the man pages that folks, in general, \nalready know the background and concepts, and are just looking for the \nparticular command option details. I.e that it is a reference manual. \nThere has been a lot of work done over the years on sub-modules but, to \nme, the concentration has been on _implementation_ (which is obviously \nimportant), rather than _explanation_ of how sub-modules work and the \nnewer capabilities mesh into the existing ones.\n\nAs seen here, the existing usage as a place holder for libraries at \nexact versions has been 'lost' in the flurry of newer capabilities. It \nmaybe something to add to the wider UX discussions [A].\n>\n> - git-submodule(1): https://git-scm.com/docs/git-submodule\n> - gitsubmodules(7): https://git-scm.com/docs/gitsubmodules\n> - gitmodules(5): https://git-scm.com/docs/gitmodules\n>\n> I hope that helps,\n>\n> Philippe.\n>\n> [1] https://git-scm.com/book/en/v2/Git-Tools-Submodules\nPhilip\n\n[A] \nhttps://lore.kernel.org/git/CA+Yb-VSaeKy-g_ywkZzQuEX=k3EXM+Ky-rHOb2az0SHGVbdaVw@mail.gmail.com/\n"},{"id":"455264","messageId":"xmqqwnepbgof.fsf@gitster.g","threadId":"57873","inReplyTo":"88fa7138-cb3f-ab88-525c-198396b0a262@gmail.com","subject":"Re: Git Submodules ref setting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-13T15:22:56Z","receivedAt":"2022-05-13T15:23:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philippe Blain writes:\n\n> Yes, it was a deliberate design choice to have a deterministic state\n> of a repository using submodules upon 'git clone'. Recording a submodule\n> at a specific branch instead of at a specific commit would make this design\n> choice impossible to achieve.\n\nThe above sentences are all correct, but it answers a slightly\ndifferent question, I think.\n\nI suspect that Vadim wanted to see if it is desirable to point at a\nnon-branch ref with \"submodule..branch\" entry (or invent a new\n\"submodule..ref\" entry) in the \".gitmodules\" file.\n\nWhile the answer to that question is \"probably not\", to understand\nwhy, your answer helps ;-).\n\nThe \"submodule..branch\" entry hints the name of the branch to\nbe used in the named submodule while working on submodule changes\nmeant to go with the change that will be made to the superproject.\n\nIt is expected that the workflow goes like this:\n\n * A contributor checks out branch X of the superproject, which\n binds another project whose name is N as its submodule at path P.\n In the tree of the commit at the tip of branch X in the\n superproject, a concrete commit C in the submodule is recorded\n at that path.\n\n * The .gitmodules file found in that superproject checkout may\n record submodule.N.branch with value Y. The commit C should be\n checked out in the submodule.\n\n * The contributor works on something that involves both the\n superproject and the submodule. Perhaps the new feature in the\n superproject requires an enhanced version of the submodule, so\n there is an dependency. New commits are added on top of C in the\n submodule, and branch Y is advanced. The commit at the tip of\n that branch is recorded in the superproject's tree, and together\n with the changes in the superproject that use the modified\n submodule advance the branch X of the superproject.\n\n * The contributor shares the work with other participants by\n pushing branch X of the superproject and branch Y of the\n submodule. There may be other branches that may be pushed out\n \"while at it\", but at least these two need to be pushed out.\n\nFor this workflow to work, it is necessary, as you said, that an\nexact commit is recorded in the tree of the superproject. We can\nguarantee a correct build of the superproject at commit at the\nupdated tip of branch X, because we know which submodule commit\nneeds to go with it.\n\nBut it is not sufficient. The history in the submodule needs to be\nmanageable---the contributors who cloned the superproject and the\nsubmodule need to check out a commit to work on and extend their\nhistories, and while it is possible to work always on detached HEAD,\nat the place where contributors meet with their work, i.e. the\nrepository their changes were pushed in the last step in the above\nsequence, there needs _some_ ref. It is possible to use a\nnon-branch ref for that, but because the contributors have to check\nthat ref out after cloning and fetching the submodule, it makes\nlittle sense not to require that ref to be a proper branch that can\nbe checked out (instead of merely giving a starting point of an\nunnamed branch, aka detached HEAD).\n\nAnd that is why \"remote..branch\" is there and it is not\n\"remote..ref\".\n\n\n\n\n\n\n"}]}