{"thread":{"id":"19432","subject":"Submodules and merge conflicts","startedAt":"2009-05-21T13:22:00Z","lastAt":"2009-05-21T20:31:39Z","messageCount":2,"participants":["Henk","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"114412","messageId":"1242912120853-2951928.post@n2.nabble.com","threadId":"19432","inReplyTo":null,"subject":"Submodules and merge conflicts","fromName":"Henk","fromEmail":"henk_westhuis@hotmail.com","sentAt":"2009-05-21T13:22:00Z","receivedAt":"2009-05-21T13:22:00Z","isPatch":false,"sender":{"key":"henk_westhuis@hotmail.com","avatar":"https://gravatar.com/avatar/cf9209436cd6db77dded64c77d6afd7a26f776d73b582ef4b3e53df0befae86b?d=mp&s=160"},"body":"\nWe have a git repository with 2 submodules structured like this:\n-Root\n -Src\n    -Scripts [Submodule]\n    -Kernel [Submodule]\n    -Web\n\nWhen someone makes changes in the Kernel submodule, the sha1 of the\nsubmodule changes. This means that the repository that uses this submodule\nalso changes because the link to the submodule changes. This very often\ncauses confusion. Co-workers very often get merge-conflicts on the submodule\nsha1 which are annoying and confusing.\n\nThe reason we like using submodules instead of having one larger repository\nis that there are seperate teams working on each module. We also use other\nversion numbers voor the kernel and the appllications using the kernel.\n\nInstead of using the sha1 of a specific revision in the submodule, I would\nfind it more logical to use a branch-name or tag. This way you can commit on\nthe submodule without having to commit the new submodule revision to the\nmain repository also.\n\nI would like to hear your thoughts on this. Maybe we are using submodules\nwrong, or maybe this is already possible.\n\nHenk Westhuis\n\n-- \nView this message in context: http://n2.nabble.com/Submodules-and-merge-conflicts-tp2951928p2951928.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"114442","messageId":"32541b130905211331u47be06afrcff2e01f0c666680@mail.gmail.com","threadId":"19432","inReplyTo":"1242912120853-2951928.post@n2.nabble.com","subject":"Re: Submodules and merge conflicts","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-05-21T20:31:39Z","receivedAt":"2009-05-21T20:31:39Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, May 21, 2009 at 9:22 AM, Henk <henk_westhuis@hotmail.com> wrote:\n> Instead of using the sha1 of a specific revision in the submodule, I would\n> find it more logical to use a branch-name or tag. This way you can commit on\n> the submodule without having to commit the new submodule revision to the\n> main repository also.\n>\n> I would like to hear your thoughts on this. Maybe we are using submodules\n> wrong, or maybe this is already possible.\n\nThe primary advantage of the git submodule code is the ability to lock\nto a specific sha1.  If you don't want to do that, you're not going to\nget much benefit from using submodules.\n\nOne option here is to simply skip the 'git submodule' altogether and\njust have a script that checks out the other git repositories into\nsubdirs.  Then you have total control over which branches, etc are\nincluded, the changes to the script (eg. to change which branch you\nwant to use) can be merged just like changes to anything else.\n\nWe do something in between on our internal projects: we use git\nsubmodules to lock in the sha-1 (it's really valuable to know\n*exactly* which version of everything was used in a particular\nrelease), but we have scripts to auto-update the sha-1 for each\nsubmodule to the tip of the right branches.\n\nFor some other projects, we also use the git-subtree tool I developed\n(http://alumnit.ca/~apenwarr/log/?m=200904#30) but given that your\nsubmodules are huge things like the Linux kernel, it's probably not\nappropriate in your case.  You might want to look at it anyway in case\nI'm wrong.\n\nHave fun,\n\nAvery\n"}]}