{"thread":{"id":"56113","subject":"Incorrect and inconsistent End-Of-Line characters in .gitmodules after \"git submodule set-branch --branch <branch_name>\"","startedAt":"2021-07-15T21:55:21Z","lastAt":"2021-08-05T18:39:13Z","messageCount":10,"participants":["Rostislav Krasny","brian m. carlson","Torsten B��gershausen","Atharva Raykar","Philippe Blain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"430273","messageId":"CANt7McFAu5gAFcgd+dejQjDQDxfcnyhz=BxSAejXGMMtGQzO_w@mail.gmail.com","threadId":"56113","inReplyTo":null,"subject":"Incorrect and inconsistent End-Of-Line characters in .gitmodules after \"git submodule set-branch --branch <branch_name>\"","fromName":"Rostislav Krasny","fromEmail":"rosti.bsd@gmail.com","sentAt":"2021-07-15T21:55:07Z","receivedAt":"2021-07-15T21:55:21Z","isPatch":false,"sender":{"key":"rosti.bsd@gmail.com","avatar":null},"body":"Hello,\n\nOriginally this bug was reported in the Git for Windows project and\ncontains two screenshots:\nhttps://github.com/git-for-windows/git/issues/3321\nJohannes Schindelin (dscho) is convinced that this is not a\nWindows-specific issue. Following is a brief description of this bug\nas I've faced it:\n\nAfter running the \"git submodule set-branch --branch master -- ms1\"\nI've noticed that the .gitmodules file is encoded with both DOS and\nUNIX End-of-Line characters simultaneously: all original lines use DOS\nEOL characters but the added \"branch = master\" line uses UNIX EOL.\n\nFound on the following environment:\n\n$ git --version --build-options\ngit version 2.32.0.windows.2\ncpu: x86_64\nbuilt from commit: 3d45ac813c4adf97fe3733c1f763ab6617d5add5\nsizeof-long: 4\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\n\n$ cmd.exe /c ver\n\nMicrosoft Windows [Version 10.0.19042.1083]\n\n$ cat /etc/install-options.txt\n\nEditor Option: VIM\nCustom Editor Path:\nDefault Branch Option:\nPath Option: Cmd\nSSH Option: OpenSSH\nTortoise Option: false\nCURL Option: OpenSSL\nCRLF Option: CRLFAlways\nBash Terminal Option: MinTTY\nGit Pull Behavior Option: Merge\nUse Credential Manager: Core\nPerformance Tweaks FSCache: Enabled\nEnable Symlinks: Enabled\nEnable Pseudo Console Support: Disabled\nEnable FSMonitor: Disabled\n\nComments of Johannes Schindelin (dscho) in the GitHub bug report:\n\n> I don't believe that Git considers its config files free game regarding line endings.\n> Therefore, I think that having DOS line endings in there is already a violation of Git's\n> assumptions. In any case, this is not a Windows-specific issue, even if DOS line\n> endings are much more prevalent on Windows than on other platforms. Please take\n> it to the Git mailing list (send plain-text messages, HTML messages are dropped\n> silently).\n"},{"id":"430384","messageId":"YPHgUuxqmKFkbEku@camp.crustytoothpaste.net","threadId":"56113","inReplyTo":"CANt7McFAu5gAFcgd+dejQjDQDxfcnyhz=BxSAejXGMMtGQzO_w@mail.gmail.com","subject":"Re: Incorrect and inconsistent End-Of-Line characters in .gitmodules after \"git submodule set-branch --branch <branch_name>\"","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-07-16T19:38:58Z","receivedAt":"2021-07-16T19:39:05Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-07-15 at 21:55:07, Rostislav Krasny wrote:\n> Hello,\n> \n> Originally this bug was reported in the Git for Windows project and\n> contains two screenshots:\n> https://github.com/git-for-windows/git/issues/3321\n> Johannes Schindelin (dscho) is convinced that this is not a\n> Windows-specific issue. Following is a brief description of this bug\n> as I've faced it:\n> \n> After running the \"git submodule set-branch --branch master -- ms1\"\n> I've noticed that the .gitmodules file is encoded with both DOS and\n> UNIX End-of-Line characters simultaneously: all original lines use DOS\n> EOL characters but the added \"branch = master\" line uses UNIX EOL.\n\nWhat behavior are you expecting to see here?  Are you expecting Git to\nwrite carriage returns when the file already uses carriage returns?\nWhat about when the file already contains mixed endings?\n\nAre you committing CRLF line endings into the repository, or are they\njust created by core.autocrlf=true (or some .gitattributes setting)?\n\nDoes this cause a functional problem with Git (or maybe another tool),\nor is it just aesthetically displeasing?\n\n> Comments of Johannes Schindelin (dscho) in the GitHub bug report:\n> \n> > I don't believe that Git considers its config files free game regarding line endings.\n> > Therefore, I think that having DOS line endings in there is already a violation of Git's\n> > assumptions. In any case, this is not a Windows-specific issue, even if DOS line\n> > endings are much more prevalent on Windows than on other platforms. Please take\n> > it to the Git mailing list (send plain-text messages, HTML messages are dropped\n> > silently).\n\nIt appears the config parsing code handles CRLF when reading by just\nturning it into a LF, so without changing the code, it wouldn't be\npossible to distinguish between the different line endings.  I don't\nknow that I agree with Dscho that CRLF line endings are right out, but I\nalso don't see always using LF line endings to be a problem.\n\nSince I don't use Windows and don't see this problem, and I'm not really\npartial to CRLF line endings anyway, I'm not especially interested in\nmaking any changes here, but I'm also not opposed to seeing a patch here\nif someone would like to send one to do something different.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"430432","messageId":"20210717170536.x2n443dtejk76wfp@tb-raspi4","threadId":"56113","inReplyTo":"CANt7McFAu5gAFcgd+dejQjDQDxfcnyhz=BxSAejXGMMtGQzO_w@mail.gmail.com","subject":"Re: Incorrect and inconsistent End-Of-Line characters in .gitmodules after \"git submodule set-branch --branch <branch_name>\"","fromName":"Torsten B��gershausen","fromEmail":"tboegi@web.de","sentAt":"2021-07-17T17:05:36Z","receivedAt":"2021-07-17T17:05:39Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Fri, Jul 16, 2021 at 12:55:07AM +0300, Rostislav Krasny wrote:\n> Hello,\n>\n> Originally this bug was reported in the Git for Windows project and\n> contains two screenshots:\n> https://github.com/git-for-windows/git/issues/3321\n> Johannes Schindelin (dscho) is convinced that this is not a\n> Windows-specific issue. Following is a brief description of this bug\n> as I've faced it:\n>\n> After running the \"git submodule set-branch --branch master -- ms1\"\n> I've noticed that the .gitmodules file is encoded with both DOS and\n> UNIX End-of-Line characters simultaneously: all original lines use DOS\n> EOL characters but the added \"branch = master\" line uses UNIX EOL.\n\nFirst of all: Thanks for posting this here.\n\nThen there are some questions, at least from my side.\nHow did you get there ?\nIn which shell did you enter the command ?\n\nCould you run\nod -c .gitmodules\nand post the results here ?\n\nOr is it possible to set up a dummy repo, which does show the problem,\nsomewhere ?\n\nWhat we appreciate is a fully reproducable receipt, so that anybody can\nreproduce the problem.\n\nI have the slight suspicion that the CR as part of CRLF had sneaked in\nsomewhere via the command line. But that is already a speculation.\n\nAnd I don't know, if there is a problem at all, or is it just cosmetics ?\n\nAnyway, a full set of commands would be good to have.\n\n\n>\n> Found on the following environment:\n>\n> $ git --version --build-options\n> git version 2.32.0.windows.2\n> cpu: x86_64\n> built from commit: 3d45ac813c4adf97fe3733c1f763ab6617d5add5\n> sizeof-long: 4\n> sizeof-size_t: 8\n> shell-path: /bin/sh\n> feature: fsmonitor--daemon\n>\n> $ cmd.exe /c ver\n>\n> Microsoft Windows [Version 10.0.19042.1083]\n>\n> $ cat /etc/install-options.txt\n>\n> Editor Option: VIM\n> Custom Editor Path:\n> Default Branch Option:\n> Path Option: Cmd\n> SSH Option: OpenSSH\n> Tortoise Option: false\n> CURL Option: OpenSSL\n> CRLF Option: CRLFAlways\n> Bash Terminal Option: MinTTY\n> Git Pull Behavior Option: Merge\n> Use Credential Manager: Core\n> Performance Tweaks FSCache: Enabled\n> Enable Symlinks: Enabled\n> Enable Pseudo Console Support: Disabled\n> Enable FSMonitor: Disabled\n>\n> Comments of Johannes Schindelin (dscho) in the GitHub bug report:\n>\n> > I don't believe that Git considers its config files free game regarding line endings.\n> > Therefore, I think that having DOS line endings in there is already a violation of Git's\n> > assumptions. In any case, this is not a Windows-specific issue, even if DOS line\n> > endings are much more prevalent on Windows than on other platforms. Please take\n> > it to the Git mailing list (send plain-text messages, HTML messages are dropped\n> > silently).\n"},{"id":"430446","messageId":"CANt7McHrYhSe3JsS8UKX8NgsUajwxQY4h9KTtXkEXdd0Be_+yw@mail.gmail.com","threadId":"56113","inReplyTo":"YPHgUuxqmKFkbEku@camp.crustytoothpaste.net","subject":"Re: Incorrect and inconsistent End-Of-Line characters in .gitmodules after \"git submodule set-branch --branch <branch_name>\"","fromName":"Rostislav Krasny","fromEmail":"rosti.bsd@gmail.com","sentAt":"2021-07-17T21:22:38Z","receivedAt":"2021-07-17T21:22:52Z","isPatch":false,"sender":{"key":"rosti.bsd@gmail.com","avatar":null},"body":"On Fri, Jul 16, 2021 at 10:39 PM brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n>\n> On 2021-07-15 at 21:55:07, Rostislav Krasny wrote:\n> > Hello,\n> >\n> > Originally this bug was reported in the Git for Windows project and\n> > contains two screenshots:\n> > https://github.com/git-for-windows/git/issues/3321\n> > Johannes Schindelin (dscho) is convinced that this is not a\n> > Windows-specific issue. Following is a brief description of this bug\n> > as I've faced it:\n> >\n> > After running the \"git submodule set-branch --branch master -- ms1\"\n> > I've noticed that the .gitmodules file is encoded with both DOS and\n> > UNIX End-of-Line characters simultaneously: all original lines use DOS\n> > EOL characters but the added \"branch = master\" line uses UNIX EOL.\n>\n> What behavior are you expecting to see here?  Are you expecting Git to\n> write carriage returns when the file already uses carriage returns?\n> What about when the file already contains mixed endings?\n\nI expect it to be consistent, like the vi editor in the Git for\nWindows distribution.\n\nIf the vi editor is used to create a new file or a file in the UNIX\nEOL format it continues to use this format.\nIf the vi editor is used to edit an already existing file with the DOS\nEOL format it continues to use that format.\nNow if the \"core.autocrlf\" option is enabled (and in Git for Windows\nit's enabled by default) all local copies of textual files are always\nconverted into the DOS format of EOL.\n\nFor example:\n\n$ vi .gitignore\n$ git add .gitignore\nwarning: LF will be replaced by CRLF in .gitignore.\nThe file will have its original line endings in your working directory\n\n> Are you committing CRLF line endings into the repository, or are they\n> just created by core.autocrlf=true (or some .gitattributes setting)?\n\nIn Git for Windows \"core.autocrlf=true\" is the default configuration.\n\n> Does this cause a functional problem with Git (or maybe another tool),\n> or is it just aesthetically displeasing?\n\nI don't know, at least in the vi editor it looks broken because of all\nthose '^M' symbols.\n\nI would like to take this opportunity to ask: why cloning a repository\nthat contains submodules sets this repository branch to its default\n(master, main, whatever) but all submodules are set into a detached\nHEAD mode instead of their default branches? This is actually the\nreason I started to check what happens with the .gitmodules file. What\nis the point in such an inconsistent behavior? There are a lot of\nquestions about that in Google and it seems most of the users expect\ndifferent behavior.\n"},{"id":"430451","messageId":"CANt7McECMjz_=EnB5NxeY9sHSzjNLXtkrqPhyLArBXJswM4xQQ@mail.gmail.com","threadId":"56113","inReplyTo":"20210717170536.x2n443dtejk76wfp@tb-raspi4","subject":"Re: Incorrect and inconsistent End-Of-Line characters in .gitmodules after \"git submodule set-branch --branch <branch_name>\"","fromName":"Rostislav Krasny","fromEmail":"rosti.bsd@gmail.com","sentAt":"2021-07-17T22:42:26Z","receivedAt":"2021-07-17T22:42:40Z","isPatch":false,"sender":{"key":"rosti.bsd@gmail.com","avatar":null},"body":"On Sat, Jul 17, 2021 at 8:05 PM Torsten Bögershausen <tboegi@web.de> wrote:\n>\n> On Fri, Jul 16, 2021 at 12:55:07AM +0300, Rostislav Krasny wrote:\n> > Hello,\n> >\n> > Originally this bug was reported in the Git for Windows project and\n> > contains two screenshots:\n> > https://github.com/git-for-windows/git/issues/3321\n> > Johannes Schindelin (dscho) is convinced that this is not a\n> > Windows-specific issue. Following is a brief description of this bug\n> > as I've faced it:\n> >\n> > After running the \"git submodule set-branch --branch master -- ms1\"\n> > I've noticed that the .gitmodules file is encoded with both DOS and\n> > UNIX End-of-Line characters simultaneously: all original lines use DOS\n> > EOL characters but the added \"branch = master\" line uses UNIX EOL.\n>\n> First of all: Thanks for posting this here.\n>\n> Then there are some questions, at least from my side.\n> How did you get there ?\n\nI just tried to use submodules and wanted to change the default state\nof the submodules (from detached HEAD into some branch) after cloning\ntheir parent repository together with the submodules. Take a look at\nmy question to Brian in this thread.\n\n> In which shell did you enter the command ?\n\nGit Bash inside MINTTY of Git for Windows\n\n$ bash --version\nGNU bash, version 4.4.23(1)-release (x86_64-pc-msys)\nCopyright (C) 2016 Free Software Foundation, Inc.\nLicense GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\n\nThis is free software; you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.\n\n> Could you run\n> od -c .gitmodules\n> and post the results here ?\n\nSure:\n$ od -c .gitmodules\n0000000   [   s   u   b   m   o   d   u   l   e       \"   m   s   1   \"\n0000020   ]  \\r  \\n  \\t   p   a   t   h       =       m   s   1  \\r  \\n\n0000040  \\t   u   r   l       =       .   .   /   m   s   1  \\r  \\n  \\t\n0000060   b   r   a   n   c   h       =       m   a   s   t   e   r  \\n\n0000100   [   s   u   b   m   o   d   u   l   e       \"   m   s   2   \"\n0000120   ]  \\r  \\n  \\t   p   a   t   h       =       m   s   2  \\r  \\n\n0000140  \\t   u   r   l       =       .   .   /   m   s   2  \\r  \\n\n0000157\n\n> Or is it possible to set up a dummy repo, which does show the problem,\n> somewhere ?\n>\n> What we appreciate is a fully reproducable receipt, so that anybody can\n> reproduce the problem.\n\nTry to do the following steps on Windows:\n1. Download https://github.com/git-for-windows/git/files/6835344/git-tryouts.tar.gz\n2. Extract the tarball and go into the git-tryouts/local-parent directory\n3. Run the \"git clone --recurse-submodules ../parent/ .\" command\n4. Run the \"git submodule set-branch --branch master -- ms1\" command\n\nNow you can check the content of the .gitmodules file for the EOL issue.\n\nOptional steps:\n\n5. try to commit the new version of the .gitmodules file and push this\ncommit back by \"git push\" command\n6. Delete everything in the git-tryouts/local-parent directory, for\nexample by the \"rm -rf .git* *\" command\n7. Do step number 3 again\n\nThere is yet another inconsistency. Right after the commit or commit\nplus push are done the .gitmodules file still has the EOL issue but\nthen after deleting everything and cloning the whole repository again\na different version of .gitmodules is created (because of\ncore.autocrlf=true). This inconsistency seems to be general and can\nhappen with any textual file on Windows.\n\n>\n> I have the slight suspicion that the CR as part of CRLF had sneaked in\n> somewhere via the command line. But that is already a speculation.\n>\n> And I don't know, if there is a problem at all, or is it just cosmetics ?\n\nAs I already answered to Brian I don't know, at least in the vi editor\nit looks broken because of all\nthose '^M' symbols.\n"},{"id":"430454","messageId":"20210718053240.bjtzggfgu7g54afn@tb-raspi4","threadId":"56113","inReplyTo":"CANt7McECMjz_=EnB5NxeY9sHSzjNLXtkrqPhyLArBXJswM4xQQ@mail.gmail.com","subject":"Re: Incorrect and inconsistent End-Of-Line characters in .gitmodules after \"git submodule set-branch --branch <branch_name>\"","fromName":"Torsten B��gershausen","fromEmail":"tboegi@web.de","sentAt":"2021-07-18T05:32:40Z","receivedAt":"2021-07-18T05:32:43Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Sun, Jul 18, 2021 at 01:42:26AM +0300, Rostislav Krasny wrote:\n> On Sat, Jul 17, 2021 at 8:05 PM Torsten B??gershausen <tboegi@web.de> wrote:\n> >\n> > On Fri, Jul 16, 2021 at 12:55:07AM +0300, Rostislav Krasny wrote:\n> > > Hello,\n> > >\n> > > Originally this bug was reported in the Git for Windows project and\n> > > contains two screenshots:\n> > > https://github.com/git-for-windows/git/issues/3321\n> > > Johannes Schindelin (dscho) is convinced that this is not a\n> > > Windows-specific issue. Following is a brief description of this bug\n> > > as I've faced it:\n> > >\n> > > After running the \"git submodule set-branch --branch master -- ms1\"\n> > > I've noticed that the .gitmodules file is encoded with both DOS and\n> > > UNIX End-of-Line characters simultaneously: all original lines use DOS\n> > > EOL characters but the added \"branch = master\" line uses UNIX EOL.\n> >\n> > First of all: Thanks for posting this here.\n> >\n> > Then there are some questions, at least from my side.\n> > How did you get there ?\n>\n> I just tried to use submodules and wanted to change the default state\n> of the submodules (from detached HEAD into some branch) after cloning\n> their parent repository together with the submodules. Take a look at\n> my question to Brian in this thread.\n>\n> > In which shell did you enter the command ?\n>\n> Git Bash inside MINTTY of Git for Windows\n>\n> $ bash --version\n> GNU bash, version 4.4.23(1)-release (x86_64-pc-msys)\n> Copyright (C) 2016 Free Software Foundation, Inc.\n> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\n>\n> This is free software; you are free to change and redistribute it.\n> There is NO WARRANTY, to the extent permitted by law.\n>\n> > Could you run\n> > od -c .gitmodules\n> > and post the results here ?\n>\n> Sure:\n> $ od -c .gitmodules\n> 0000000   [   s   u   b   m   o   d   u   l   e       \"   m   s   1   \"\n> 0000020   ]  \\r  \\n  \\t   p   a   t   h       =       m   s   1  \\r  \\n\n> 0000040  \\t   u   r   l       =       .   .   /   m   s   1  \\r  \\n  \\t\n> 0000060   b   r   a   n   c   h       =       m   a   s   t   e   r  \\n\n> 0000100   [   s   u   b   m   o   d   u   l   e       \"   m   s   2   \"\n> 0000120   ]  \\r  \\n  \\t   p   a   t   h       =       m   s   2  \\r  \\n\n> 0000140  \\t   u   r   l       =       .   .   /   m   s   2  \\r  \\n\n> 0000157\n>\n> > Or is it possible to set up a dummy repo, which does show the problem,\n> > somewhere ?\n> >\n> > What we appreciate is a fully reproducable receipt, so that anybody can\n> > reproduce the problem.\n>\n> Try to do the following steps on Windows:\n> 1. Download https://github.com/git-for-windows/git/files/6835344/git-tryouts.tar.gz\n> 2. Extract the tarball and go into the git-tryouts/local-parent directory\n> 3. Run the \"git clone --recurse-submodules ../parent/ .\" command\n> 4. Run the \"git submodule set-branch --branch master -- ms1\" command\n>\n> Now you can check the content of the .gitmodules file for the EOL issue.\n\nThanks for the reproducing receipe.\nI didn't manage to get there, but this was not on a Windows box.\nI still suspect that this has nothing to do with core.autocrlf.\nsince it never produces \"mixed\" line endings.\n(both CRLF and LF in the same file).\nIs anybody else able to reproduce it ?\n\nuser@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent> less .gitmodules\nuser@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent> od -c  .gitmodules\n0000000    [   s   u   b   m   o   d   u   l   e       \"   m   s   1   \"\n0000020    ]  \\n  \\t   p   a   t   h       =       m   s   1  \\n  \\t   u\n0000040    r   l       =       .   .   /   m   s   1  \\n   [   s   u   b\n0000060    m   o   d   u   l   e       \"   m   s   2   \"   ]  \\n  \\t   p\n0000100    a   t   h       =       m   s   2  \\n  \\t   u   r   l       =\n0000120        .   .   /   m   s   2  \\n\n0000130\nuser@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent> git config core.autocrlf true\nuser@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent> git submodule set-branch --branch master -- ms1\nuser@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent> od -c  .gitmodules\n0000000    [   s   u   b   m   o   d   u   l   e       \"   m   s   1   \"\n0000020    ]  \\n  \\t   p   a   t   h       =       m   s   1  \\n  \\t   u\n0000040    r   l       =       .   .   /   m   s   1  \\n  \\t   b   r   a\n0000060    n   c   h       =       m   a   s   t   e   r  \\n   [   s   u\n0000100    b   m   o   d   u   l   e       \"   m   s   2   \"   ]  \\n  \\t\n0000120    p   a   t   h       =       m   s   2  \\n  \\t   u   r   l\n0000140    =       .   .   /   m   s   2  \\n\n0000151\nuser@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent>\n\n\n\n\n>\n> Optional steps:\n>\n> 5. try to commit the new version of the .gitmodules file and push this\n> commit back by \"git push\" command\n> 6. Delete everything in the git-tryouts/local-parent directory, for\n> example by the \"rm -rf .git* *\" command\n> 7. Do step number 3 again\n>\n> There is yet another inconsistency. Right after the commit or commit\n> plus push are done the .gitmodules file still has the EOL issue but\n> then after deleting everything and cloning the whole repository again\n> a different version of .gitmodules is created (because of\n> core.autocrlf=true). This inconsistency seems to be general and can\n> happen with any textual file on Windows.\n>\n> >\n> > I have the slight suspicion that the CR as part of CRLF had sneaked in\n> > somewhere via the command line. But that is already a speculation.\n> >\n> > And I don't know, if there is a problem at all, or is it just cosmetics ?\n>\n> As I already answered to Brian I don't know, at least in the vi editor\n> it looks broken because of all\n> those '^M' symbols.\n"},{"id":"430741","messageId":"46F5B91F-4DBE-4F34-9395-7CC808FAC359@gmail.com","threadId":"56113","inReplyTo":"CANt7McHrYhSe3JsS8UKX8NgsUajwxQY4h9KTtXkEXdd0Be_+yw@mail.gmail.com","subject":"Why do submodules detach HEAD? (was Re: Incorrect and inconsistent End-Of-Line characters in .gitmodules ...)","fromName":"Atharva Raykar","fromEmail":"raykar.ath@gmail.com","sentAt":"2021-07-21T07:26:14Z","receivedAt":"2021-07-21T07:31:01Z","isPatch":false,"sender":{"key":"raykar.ath@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24277692?v=4"},"body":"On 18-Jul-2021, at 02:52, Rostislav Krasny <rosti.bsd@gmail.com> wrote:\n> \n> \n> [...]\n> I would like to take this opportunity to ask: why cloning a repository\n> that contains submodules sets this repository branch to its default\n> (master, main, whatever) but all submodules are set into a detached\n> HEAD mode instead of their default branches? This is actually the\n> reason I started to check what happens with the .gitmodules file. What\n> is the point in such an inconsistent behavior? There are a lot of\n> questions about that in Google and it seems most of the users expect\n> different behavior.\n\nSubmodules are cloned along with the parent repository only when\n'submodule.recurse' is set to true, which I assume is the case for\nyour configuration.\n\nA git clone that recurses submodules is equivalent to running\n'git submodule update --init --recursive' right after the parent\nproject has been cloned.\n\nThe default mode for the update command is to checkout to the\nrevision that the parent project expects the submodule to be in, ie,\nit checks out to the commit hash directly, and detaches the HEAD.\n\nWhy not checkout to a branch? This is because branches may change\nwhich commits they point to.\n\nFor example, if you had a submodule 'foo'. I go into the 'foo'\nfolder and amend the last commit.\n\nNow if I run 'submodule update' in the parent repository. If it had\nchecked out to the branch instead of the revision, I would be on a\ndifferent commit in 'foo' than the one that was registered by the\nparent repo!\n\nWe want to have idempotence, ie, for a particular revision that is\nregistered by our parent project, we want 'update' to give the same\noutcome every time, and not be dependent on whatever the state of the\nbranch is. This way we ensure that for a particular commit in the\nparent project, the submodules will be in the same state for every\nsystem in the world, after an 'update' is run.\n\nI hope that makes sense.\n\n(Anyone more knowledgeable than me in submodules, feel free to add\nto what I am saying and correct me if I made an error!)\n\n---\nAtharva Raykar\nಅಥರ್ವ ರಾಯ್ಕರ್\nअथर्व रायकर\n\n"},{"id":"430807","messageId":"9d39da2c-1450-d462-5d80-13112a529c2e@gmail.com","threadId":"56113","inReplyTo":"46F5B91F-4DBE-4F34-9395-7CC808FAC359@gmail.com","subject":"Re: Why do submodules detach HEAD? (was Re: Incorrect and inconsistent End-Of-Line characters in .gitmodules ...)","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2021-07-21T22:42:27Z","receivedAt":"2021-07-21T22:42:32Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Atharva,\n\nLe 2021-07-21 à 03:26, Atharva Raykar a écrit :\n> On 18-Jul-2021, at 02:52, Rostislav Krasny <rosti.bsd@gmail.com> wrote:\n>>\n>>\n>> [...]\n>> I would like to take this opportunity to ask: why cloning a repository\n>> that contains submodules sets this repository branch to its default\n>> (master, main, whatever) but all submodules are set into a detached\n>> HEAD mode instead of their default branches? This is actually the\n>> reason I started to check what happens with the .gitmodules file. What\n>> is the point in such an inconsistent behavior? There are a lot of\n>> questions about that in Google and it seems most of the users expect\n>> different behavior.\n> \n> Submodules are cloned along with the parent repository only when\n> 'submodule.recurse' is set to true, which I assume is the case for\n> your configuration.\n\nCorrection: no, 'git clone' always needs to be given the '--recurse-submodules' (or its old\nalias, '--recursive') for submodules to be cloned. It does *not* honor\n'submodule.recurse' (that's documented at [1]).\n\nShould it honor it ?\nSome people think yes, but others think no (mostly people that deal with repos with a huge number\nof submodules which are optional, and thus would not want *all* submodules to be cloned\neven if 'submodule.recurse' is set) . This has been discussed before,\nand several tries were done to change that but for now the behaviour remains.\nI personnally think that marking some submodules as optional should\nbe something that can be tracked in '.gitmodules', and a future version of Git\nwould clone all *non-optional* submodules if 'submodule.recurse' is set (some think\nit should do so even if it's not set.) The most recent discussion about that, I think,\nit at [2].\n\n> \n> -- 8< --\n> \n> I hope that makes sense.\n> \n> (Anyone more knowledgeable than me in submodules, feel free to add\n> to what I am saying and correct me if I made an error!)\n> \n\nThe rest of what you wrote is perfectly clear and correct.\nKeep up the good work on your GSOC project ! :)\n\n\nCheers,\n\nPhilippe.\n\n[1] https://git-scm.com/docs/git-config#Documentation/git-config.txt-submodulerecurse\n[2] https://lore.kernel.org/git/0fc5c0f7-52f7-fb36-f654-ff5223a8809b@gmail.com/\n\n"},{"id":"432102","messageId":"CANt7McE4N0wv5bik8tSNrdTs-mcL20cJPMP42iPtZqhUpKgirA@mail.gmail.com","threadId":"56113","inReplyTo":"46F5B91F-4DBE-4F34-9395-7CC808FAC359@gmail.com","subject":"Re: Why do submodules detach HEAD? (was Re: Incorrect and inconsistent End-Of-Line characters in .gitmodules ...)","fromName":"Rostislav Krasny","fromEmail":"rosti.bsd@gmail.com","sentAt":"2021-08-05T13:59:54Z","receivedAt":"2021-08-05T14:00:09Z","isPatch":false,"sender":{"key":"rosti.bsd@gmail.com","avatar":null},"body":"On Wed, Jul 21, 2021 at 10:26 AM Atharva Raykar <raykar.ath@gmail.com> wrote:\n> The default mode for the update command is to checkout to the\n> revision that the parent project expects the submodule to be in, ie,\n> it checks out to the commit hash directly, and detaches the HEAD.\n>\n> Why not checkout to a branch? This is because branches may change\n> which commits they point to.\n>\n> For example, if you had a submodule 'foo'. I go into the 'foo'\n> folder and amend the last commit.\n>\n> Now if I run 'submodule update' in the parent repository. If it had\n> checked out to the branch instead of the revision, I would be on a\n> different commit in 'foo' than the one that was registered by the\n> parent repo!\n>\n> We want to have idempotence, ie, for a particular revision that is\n> registered by our parent project, we want 'update' to give the same\n> outcome every time, and not be dependent on whatever the state of the\n> branch is. This way we ensure that for a particular commit in the\n> parent project, the submodules will be in the same state for every\n> system in the world, after an 'update' is run.\n\nAll this is ok, but there could be other uses of sub-modules. Why not\nto make this behavior configurable?\n\nAs a developer I may want to make new commits on those sub-modules and\nalways work with latest versions of their particular branches. In the\ndetached HEAD mode this is much harder to be done and also an error\nprone operation. Commits that are done in the detached HEAD state may\neasily be lost. Google is full of questions about how this could be\ndone, i.e. there is an essential demand of such a new behavior.\n"},{"id":"432122","messageId":"m2bl6bvit1.fsf@gmail.com","threadId":"56113","inReplyTo":"CANt7McE4N0wv5bik8tSNrdTs-mcL20cJPMP42iPtZqhUpKgirA@mail.gmail.com","subject":"Re: Why do submodules detach HEAD? (was Re: Incorrect and inconsistent End-Of-Line characters in .gitmodules ...)","fromName":"Atharva Raykar","fromEmail":"raykar.ath@gmail.com","sentAt":"2021-08-05T18:38:02Z","receivedAt":"2021-08-05T18:39:13Z","isPatch":false,"sender":{"key":"raykar.ath@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24277692?v=4"},"body":"\nRostislav Krasny <rosti.bsd@gmail.com> writes:\n\n> On Wed, Jul 21, 2021 at 10:26 AM Atharva Raykar <raykar.ath@gmail.com> wrote:\n>> [...]\n>> We want to have idempotence, ie, for a particular revision that is\n>> registered by our parent project, we want 'update' to give the same\n>> outcome every time, and not be dependent on whatever the state of the\n>> branch is. This way we ensure that for a particular commit in the\n>> parent project, the submodules will be in the same state for every\n>> system in the world, after an 'update' is run.\n>\n> All this is ok, but there could be other uses of sub-modules. Why not\n> to make this behavior configurable?\n>\n> As a developer I may want to make new commits on those sub-modules and\n> always work with latest versions of their particular branches. In the\n> detached HEAD mode this is much harder to be done and also an error\n> prone operation. Commits that are done in the detached HEAD state may\n> easily be lost. [...]\n\nHave you tried running 'submodule update --merge' or\n'submodule update --rebase'? Those modes will not detach your\nsubmodule's HEAD.\n\nThe Pro Git book has a section that explains a workflow that sounds\nsimilar to what you describe:\n\nhttps://git-scm.com/book/en/v2/Git-Tools-Submodules\n\nAround halfway down the page, look for the heading \"Working on a\nSubmodule\". Does that fit your use case?\n\n> [...] Google is full of questions about how this could be done, i.e. there\n> is an essential demand of such a new behavior.\n\nIt would be nice if you can share a specific link that captures the\ndemand you are talking about. When I Googled about this behaviour, I got\na range of different kinds of results, without a clearly voiced demand.\nIf you can show an example that best represents this demand, the Git\ndevelopers here may be able to address it better.\n"}]}