Git dialog sporatically does not open

[pa-0]

So I'd say a good 80% of the time, the git integration works as expected, without any hitch. Sometimes however, MM requires a restart before the Git dialog will appear. I say it's sporatic because it will occur when conditions are the same, i.e., working in the same repositority and the same file is open / selected on first attempt as is on the second attempt (after restart). On other occassions, again, when working in or selecting the same file in the same repository, the "Commit to Git" menu item will be greyed out. I have yet to find any consistently present condition that might explain this, since after restart, the menu item will no longer be greyed out despite my working in the same file as before:

[pa-0]

To clarify, in the first scenario, "Commit to Git" will not be greyed out; however, selecting the option produces no results, even after waiting for some time (as long as ten minutes) for the dialog to appear to see if it's just a lag.

[RickStrahl]

Hmmm... I haven't seen that behavior. I have seen some instances where commit doesn't want to work unless the Git folder is 'refreshed' by exting the dialog and coming back in, but it's not the same as what you describe which is hanging. I've seen this slow at times though.

If it's not enabled that would suggest there's nothing to commit. If you still want to access the dialog you can use the Git icon from the toolbar and it will bring up an empty commit dialog.

Do the Git icons show in the folder browser and are there any files that are updated/new?

[pa-0]

Yes. The git icons are 100% always present. Never had any issues there. The hover tip that describes the state of the Git Working directory, and the file under the cursor in relation to the Git Working directory, also work consistently without fail.

[pa-0]

So I can open a new issue for this if you prefer, but another problem with the git integration (just appeared with 3.5.5.5 release):

Immediately after committing and pushing, if open the same file I just committed without editing it at all, and then opening Git, the red checkmark appears next to the open file (and remains there) indicating that the file has been edited. I can go down the line of files visible in the file browser, and if I repeat this process with each, I end up with a folder full of files that all appear to have unstaged changes.

[pa-0]

I take that back, it does not affect all files. Is it possible that these files have CRLF and line endings and MM is normalizing these documents to conform with the default I have set? (LF)

[RickStrahl]

MM will normalize open files to whatever your line feed setting is. If a Git Commit changes the from CRLF to LF, the editor will detect the change and reload that file, but with the line feed settings that MM has set. When you then save the file will appear changed.

So, if you have Git set to LF you probably should also set MM to use LF instead of CRLF.

There's a setting for CRLF handling in Git that can help avoid some of that but how this works is confusing AF as even with these settings I constantly see Git warning about the CRLF conflicts.

https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings

I use:

• text=auto eol=lf

in .gitattributes and that seems to work well-ish.

[pa-0]

So one of the problems with gitattributes is git won't respect it (by design) if commits have already been made in the repository with a different EOL-setting in gitconfig (one that conflicts with the gitattributes EOL setting). For example if you have your global gitconfig EOL-type set to auto, adding a setting for a specific EOL to a gitattribute in an existing repository won't have any effect unless you run a git command to normalize the affected files to match that setting. At least that's my understanding.

As far as the original issue, I think the problem is actually (maybe?) user-error? I don't know if it's by design, but it seems like the dialog won't appear if I attempt to activate it via shortcut with a file open that hasn't yet been modified since the last commit, even if the git working directory does have modified files in the working directory. I think this was the source of my confusion. Now, if I open a modified file and trigger the Git shortcut in MM, it opens without issue.

[pa-0]

As always, thanks for taking the time.