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 [off-list ref] wrote:

On Fri, Jul 16, 2021 at 12:55:07AM +0300, Rostislav Krasny wrote:

quoted

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.