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

> 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.

>
> 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.