Re: Incorrect and inconsistent End-Of-Line characters in .gitmodules after "git submodule set-branch --branch <branch_name>"

[Torsten =?unknown-8bit?Q?B=C3=B6gershausen?= <tboegi@web.de>]

On Sun, Jul 18, 2021 at 01:42:26AM +0300, Rostislav Krasny wrote:
> On Sat, Jul 17, 2021 at 8:05 PM Torsten B??gershausen <tboegi@web.de> wrote:
> >
> > On Fri, Jul 16, 2021 at 12:55:07AM +0300, Rostislav Krasny wrote:
> > > Hello,
> > >
> > > Originally this bug was reported in the Git for Windows project and
> > > contains two screenshots:
> > > https://github.com/git-for-windows/git/issues/3321
> > > Johannes Schindelin (dscho) is convinced that this is not a
> > > Windows-specific issue. Following is a brief description of this bug
> > > as I've faced it:
> > >
> > > After running the "git submodule set-branch --branch master -- ms1"
> > > I've noticed that the .gitmodules file is encoded with both DOS and
> > > UNIX End-of-Line characters simultaneously: all original lines use DOS
> > > EOL characters but the added "branch = master" line uses UNIX EOL.
> >
> > First of all: Thanks for posting this here.
> >
> > Then there are some questions, at least from my side.
> > How did you get there ?
>
> I just tried to use submodules and wanted to change the default state
> of the submodules (from detached HEAD into some branch) after cloning
> their parent repository together with the submodules. Take a look at
> my question to Brian in this thread.
>
> > In which shell did you enter the command ?
>
> Git Bash inside MINTTY of Git for Windows
>
> $ bash --version
> GNU bash, version 4.4.23(1)-release (x86_64-pc-msys)
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> > Could you run
> > od -c .gitmodules
> > and post the results here ?
>
> Sure:
> $ od -c .gitmodules
> 0000000   [   s   u   b   m   o   d   u   l   e       "   m   s   1   "
> 0000020   ]  \r  \n  \t   p   a   t   h       =       m   s   1  \r  \n
> 0000040  \t   u   r   l       =       .   .   /   m   s   1  \r  \n  \t
> 0000060   b   r   a   n   c   h       =       m   a   s   t   e   r  \n
> 0000100   [   s   u   b   m   o   d   u   l   e       "   m   s   2   "
> 0000120   ]  \r  \n  \t   p   a   t   h       =       m   s   2  \r  \n
> 0000140  \t   u   r   l       =       .   .   /   m   s   2  \r  \n
> 0000157
>
> > Or is it possible to set up a dummy repo, which does show the problem,
> > somewhere ?
> >
> > What we appreciate is a fully reproducable receipt, so that anybody can
> > reproduce the problem.
>
> Try to do the following steps on Windows:
> 1. Download https://github.com/git-for-windows/git/files/6835344/git-tryouts.tar.gz
> 2. Extract the tarball and go into the git-tryouts/local-parent directory
> 3. Run the "git clone --recurse-submodules ../parent/ ." command
> 4. Run the "git submodule set-branch --branch master -- ms1" command
>
> Now you can check the content of the .gitmodules file for the EOL issue.

Thanks for the reproducing receipe.
I didn't manage to get there, but this was not on a Windows box.
I still suspect that this has nothing to do with core.autocrlf.
since it never produces "mixed" line endings.
(both CRLF and LF in the same file).
Is anybody else able to reproduce it ?

user@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent> less .gitmodules
user@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent> od -c  .gitmodules
0000000    [   s   u   b   m   o   d   u   l   e       "   m   s   1   "
0000020    ]  \n  \t   p   a   t   h       =       m   s   1  \n  \t   u
0000040    r   l       =       .   .   /   m   s   1  \n   [   s   u   b
0000060    m   o   d   u   l   e       "   m   s   2   "   ]  \n  \t   p
0000100    a   t   h       =       m   s   2  \n  \t   u   r   l       =
0000120        .   .   /   m   s   2  \n
0000130
user@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent> git config core.autocrlf true
user@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent> git submodule set-branch --branch master -- ms1
user@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent> od -c  .gitmodules
0000000    [   s   u   b   m   o   d   u   l   e       "   m   s   1   "
0000020    ]  \n  \t   p   a   t   h       =       m   s   1  \n  \t   u
0000040    r   l       =       .   .   /   m   s   1  \n  \t   b   r   a
0000060    n   c   h       =       m   a   s   t   e   r  \n   [   s   u
0000100    b   m   o   d   u   l   e       "   m   s   2   "   ]  \n  \t
0000120    p   a   t   h       =       m   s   2  \n  \t   u   r   l
0000140    =       .   .   /   m   s   2  \n
0000151
user@mac:/tmp/2021-07-18-git-submodules-CRLF/git-tryouts/local-parent>




>
> Optional steps:
>
> 5. try to commit the new version of the .gitmodules file and push this
> commit back by "git push" command
> 6. Delete everything in the git-tryouts/local-parent directory, for
> example by the "rm -rf .git* *" command
> 7. Do step number 3 again
>
> There is yet another inconsistency. Right after the commit or commit
> plus push are done the .gitmodules file still has the EOL issue but
> then after deleting everything and cloning the whole repository again
> a different version of .gitmodules is created (because of
> core.autocrlf=true). This inconsistency seems to be general and can
> happen with any textual file on Windows.
>
> >
> > I have the slight suspicion that the CR as part of CRLF had sneaked in
> > somewhere via the command line. But that is already a speculation.
> >
> > And I don't know, if there is a problem at all, or is it just cosmetics ?
>
> As I already answered to Brian I don't know, at least in the vi editor
> it looks broken because of all
> those '^M' symbols.