On Sat, Jul 17, 2021 at 8:05 PM Torsten Bögershausen <tboegi@xxxxxx> 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.
