search

sindresorhus / editorconfig-sublime

Sublime Text plugin for EditorConfig - Helps developers maintain consistent coding styles between different editors
MIT License
1.77k stars 107 forks source link

Breaks git commit -v (git commit --verbose) #55

Closed daniel-liuzzi closed 4 years ago

daniel-liuzzi commented 8 years ago

Issuehunt badges

According to the documentation for git-commit (emphasis mine)

-v --verbose Show unified diff between the HEAD commit and what would be committed at the bottom of the commit message template to help the user describe the commit by reminding what changes the commit has. Note that this diff output doesn’t have its lines prefixed with #. This diff will not be a part of the commit message.

Git is apparently able to ignore the diff block thanks to a marker preceding it, which looks like this:

# ------------------------ >8 ------------------------
# Do not touch the line above.
# Everything below will be removed.
#

Today I've discovered that the plugin causes the full diff to be included in the commit message (disabling/uninstalling it fixes the problem.) I'm assuming it must be messing with the "Do not touch the line above." line, causing Git to get confused.

I could add a [COMMIT_EDITMSG] section to my .editorconfig file to try and have this file left alone, but this feels hackish. Furthermore, adding this to every repository would get tiresome.

I wonder if there is a more elegant solution to this. git commit -v is just too good to give up!

In case it matters, this is my .editorconfig file:

root = true

[*]
end_of_line = crlf
indent_size = 4
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true
IssueHunt Summary #### [vogu66 vogu66](https://issuehunt.io/u/vogu66) has been rewarded. ### Backers (Total: $40.00) - [issuehunt issuehunt](https://issuehunt.io/u/issuehunt) ($40.00) ### Submitted pull Requests - [#88 Solve issue #55 with lf line endings in .git folders](https://issuehunt.io/r/sindresorhus/editorconfig-sublime/pull/88) --- ### Tips - Checkout the [Issuehunt explorer](https://issuehunt.io/r/sindresorhus/editorconfig-sublime/) to discover more funded issues. - Need some help from other developers? [Add your repositories](https://issuehunt.io/r/new) on IssueHunt to raise funds.
sindresorhus commented 8 years ago

Could just ignore the COMMIT_EDITMSG filename in this plugin.

daniel-liuzzi commented 8 years ago

I think either that or even .git/* would work. I'm trying to think of a use case for manually editing (and normalizing styles of) raw git objects, but I can't come up with any. I could be wrong, though.

sindresorhus commented 8 years ago

Pull request welcome if anyone wants to see this resolved :)

issuehunt-oss[bot] commented 5 years ago

@issuehunt has funded $40.00 to this issue.

schedutron commented 4 years ago

If no one's on it, can I work on resolving this?

vogu66 commented 4 years ago

It happens because of the line ending. By default apparently the line ending is "lf" for git (which is default on Linux and on git for Windows, I guess it may change on Mac but I doubt it), and with the crlf line ending the line that "should not be touched" is modified so git doesn't recognize it.

Here is the log for the three file endings, the result is the same for atom :

commit e72f30c6c5498dd6c22ec7b73e1c0d36066c1817
Author: vogu66 <24728720+vogu66@users.noreply.github.com>
Date:   Fri Jul 3 15:29:31 2020 +0200

    test end of file crlf
    diff --git a/.editorconfig b/.editorconfig
    index 3b8dae8..71e2d4d 100644
    --- a/.editorconfig
    +++ b/.editorconfig
    @@ -1,7 +1,7 @@
     root = true

     [*]
    -end_of_line = cr
    +end_of_line = crlf
     indent_size = 4
     indent_style = space
     insert_final_newline = true

commit 0850218b5175e3061f490e454130e745f4fd9fd5
Author: vogu66 <24728720+vogu66@users.noreply.github.com>
Date:   Fri Jul 3 15:29:03 2020 +0200

    test end of file cr^M# Please enter the commit message for your changes. Lines starting^M# with '#' will be ignored, and an empty message aborts the commit.^M# On branch master^M# Changes to be committed:^M#     modified:   .editorconfig^M#^M# ------------------------ >8 ------------------------^M# Do not touch the line above.^M# Everything below will be removed.^Mdiff --git a/.editorconfig b/.editorconfig^Mindex dbced28..3b8dae8 100644^M--- a/.editorconfig^M+++ b/.editorconfig^M@@ -1,7 +1,7 @@^M root = true^M [*]^M-end_of_line = lf^M+end_of_line = cr^M indent_size = 4^M indent_style = space^M insert_final_newline = true

commit 405a71b55869659cc96c48885ae9818144cae6fa
Author: vogu66 <24728720+vogu66@users.noreply.github.com>
Date:   Fri Jul 3 15:28:37 2020 +0200

    test end of file lf

When using lf, the file is unchanged. When using cr, git doesn't recognize more than one line so everything is there. When using crlf, the line which shouldn't be touched in the commit has an added "cr" so git doesn't recognize it and considers the rest as not a diff but a comment.

In git config, there is only an issue for "cr" line endings, which give a fatal error, the crlf line endings seem to work fine.

The solution in this plugin would be to ignore the end_of_line property for .git/* namespace, and also tell the git developers they should take that into account I suppose. I'm not sure what the default line ending for git on mac is, but for now I've got a local copy of the repo modified to set the "end_of_line" property to "lf" when there is /.git/ somewhere in the path.

I'm not sure if it's better that or just check if the parent directory is .git, since I have no idea whether line endings have an influence on git hooks -- which are, to my knowledge, the only use case of things modified manually in a subfolder of .git.

If someone could check the line endings on mac it would be nice, the procedure would be something like :

$ mkdir test-git
$ cd test-git
$ git init
$ git config core.editor 'subl -w' # note that I'm not entirely sure for this,
    # but it should be something similar, it's like this on Linux at least
$ touch stuff # supposing Mac has the touch command, just make any change
$ git add --all
$ git commit -v # then type a random message, and make sure to check the line ending,
    # either with this plugin or with sublime text
$ git log # to see if there is more than your random message in the log

And the line ending that has the right message should be the default, probably "Unix" or "lf" (depending on the way it was set).

If it's "lf" then I've got a working solution; if it's not I guess I need to add an OS check.

vogu66 commented 4 years ago

also, @schedutron, sorry if you were working on this but since it's been 6 months I thought you likely abandoned the issue, and it wasn't really hard to solve, so I just solved it

issuehunt-oss[bot] commented 4 years ago

@sindresorhus has rewarded $36.00 to @vogu66. See it on IssueHunt