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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jul 16, 2021, 19:38 UTC
Message-ID: <YPHgUuxqmKFkbEku@camp.crustytoothpaste.net>
In-Reply-To: <CANt7McFAu5gAFcgd+dejQjDQDxfcnyhz=BxSAejXGMMtGQzO_w@mail.gmail.com>

On 2021-07-15 at 21:55:07, Rostislav Krasny wrote:

Show 13 quoted lines

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

Are you committing CRLF line endings into the repository, or are they just created by core.autocrlf=true (or some .gitattributes setting)?

Does this cause a functional problem with Git (or maybe another tool), or is it just aesthetically displeasing?

Show 8 quoted lines

> Comments of Johannes Schindelin (dscho) in the GitHub bug report:
> 
> > I don't believe that Git considers its config files free game regarding line endings.
> > Therefore, I think that having DOS line endings in there is already a violation of Git's
> > assumptions. In any case, this is not a Windows-specific issue, even if DOS line
> > endings are much more prevalent on Windows than on other platforms. Please take
> > it to the Git mailing list (send plain-text messages, HTML messages are dropped
> > silently).

It appears the config parsing code handles CRLF when reading by just turning it into a LF, so without changing the code, it wouldn't be possible to distinguish between the different line endings. I don't know that I agree with Dscho that CRLF line endings are right out, but I also don't see always using LF line endings to be a problem.

Since I don't use Windows and don't see this problem, and I'm not really partial to CRLF line endings anyway, I'm not especially interested in making any changes here, but I'm also not opposed to seeing a patch here if someone would like to send one to do something different.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA