Skip to content

Conversation

@mosquito-magnet
Copy link

@mosquito-magnet mosquito-magnet commented Dec 3, 2021

Hi,

When running git-gutter on files with encodings incompatible with the Emacs default encoding (prefer-coding-system), several problems can occur:

  • When reading incompatible file content data from processes the receiving buffers would contain bytes incompatible with their (default) encoding.
  • Writing contents from these buffers to file (git-gutter-orig/git-gutter-cur) would prompt user for proper encoding, if Emacs could not automatically determine a safe one.
  • Original/current temporary files with improper/deviating encoding yield incorrect diff results.
  • When staging, patch files with improper encoding would not apply.
  • Popup hunk buffer could display garbled characters.

To fix this, use the current workdir file encoding to set read and write encodings where appropriate. This assumes the unchanged file uses the same encoding, so there are still error situations possible if that encoding is incompatible with the workdir file one. This should be good enough for most situations though.

Closes #176
Supersedes #177

error reproduction

Make emacs use utf-8 as default, if not already the case: (prefer-coding-system 'utf-8)
Create a new git repo, commit a file with windows-1252-dos encoding, and some umlaut chars, e.g.: windows-1252-dos.txt
Open the file and enable git-gutter.
When git-gutter:live-update runs, a prompt for choosing encoding of writing the temporary file with original file content should pop up.

When running git-gutter on files with encodings incompatible with the
emacs default encoding (prefer-coding-system), several problems could
occur.

When reading incompatible file content data from processes the receiving
buffers would contain bytes with their (default) encoding.

Writing contents from these buffers to file (original/current) would
prompt user for proper encoding, if it could not automatically determine
a safe one.

Original/current temporary files with improper/deviating encoding yield
incorrect diff results.

On staging, patch files with improper encoding would not apply.

Popup hunk buffer could display garbled characters.

To fix this, use the current workdir file encoding to set read and write
encodings where appropriate. This assumes the unchanged file uses the
same encoding, so there are still error situations possible if that
encoding is incompatible with the workdir file one. This should be good
enough for most situations though.
@gonewest818
Copy link
Collaborator

Catching up on old pull requests and I'm not able to reproduce this... When time permits I'll strip down my configuration and try again.

1 similar comment
@gonewest818
Copy link
Collaborator

Catching up on old pull requests and I'm not able to reproduce this... When time permits I'll strip down my configuration and try again.

@jzb-hpe
Copy link

jzb-hpe commented Dec 8, 2023

This PR should be merged! Ignore the obvious regressions against current version, but the buffer-file-coding-system stuff works! I've had a long-standing corner case issue that is best described here:

https://www.reddit.com/r/emacs/comments/168z11w/gitgutter_makes_entire_file_as_modified_when_it/

In my case, it was git files accessed from a linux vm on a windows host going through a 'shared-folder' into the windows underlying disk storage, where the git clone was run (from linux vm) with autocrlf=true and eol=crlf. This resulted in DOS-style file-endings on checkout, and some files, without any identifiable pattern, were displayed as the EOL being a diff for every line in the file, as if the rendering from DOS file on disk into the buffer somehow counted as a diff against the line-ending, though neither 'git diff' nor 'vc-diff' agreed with that assessment. But some other files, same encoding, didn't suffer from this bizarre anomaly. I've always suspected it was something to do with the file-encoding, but no matter what I did, I couldn't affect the behaviour. However, now, I am happy to report that this patch fixes said issue, at least for my scenario, and I suspect it fixes for the linked reddit as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Fails to stage hunk on Windows when file uses LF (unix) line endings

3 participants