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

From: Rostislav Krasny <rosti.bsd@gmail.com>
Date: Jul 17, 2021, 22:42 UTC
Message-ID: <CANt7McECMjz_=EnB5NxeY9sHSzjNLXtkrqPhyLArBXJswM4xQQ@mail.gmail.com>
In-Reply-To: <20210717170536.x2n443dtejk76wfp@tb-raspi4>

On Sat, Jul 17, 2021 at 8:05 PM Torsten Bögershausen <tboegi@web.de> wrote:

Show 20 quoted lines

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

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

Show 5 quoted lines

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

Show 5 quoted lines

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