On Fri, Jul 16, 2021 at 10:39 PM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2021-07-15 at 21:55:07, 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. > > What behavior are you expecting to see here? Are you expecting Git to > write carriage returns when the file already uses carriage returns? > What about when the file already contains mixed endings? I expect it to be consistent, like the vi editor in the Git for Windows distribution. If the vi editor is used to create a new file or a file in the UNIX EOL format it continues to use this format. If the vi editor is used to edit an already existing file with the DOS EOL format it continues to use that format. Now if the "core.autocrlf" option is enabled (and in Git for Windows it's enabled by default) all local copies of textual files are always converted into the DOS format of EOL. For example: $ vi .gitignore $ git add .gitignore warning: LF will be replaced by CRLF in .gitignore. The file will have its original line endings in your working directory > Are you committing CRLF line endings into the repository, or are they > just created by core.autocrlf=true (or some .gitattributes setting)? In Git for Windows "core.autocrlf=true" is the default configuration. > Does this cause a functional problem with Git (or maybe another tool), > or is it just aesthetically displeasing? I don't know, at least in the vi editor it looks broken because of all those '^M' symbols. I would like to take this opportunity to ask: why cloning a repository that contains submodules sets this repository branch to its default (master, main, whatever) but all submodules are set into a detached HEAD mode instead of their default branches? This is actually the reason I started to check what happens with the .gitmodules file. What is the point in such an inconsistent behavior? There are a lot of questions about that in Google and it seems most of the users expect different behavior.
