This is an issue I've noticed on and off for a while, but has become more of an issue lately.
The following is all described from observations in Safe Mode, motivated by similar behavior outside of Safe Mode.
When I have changes to a file an I only want to stage some changes, I open the Git view and click a file listed under Unstaged Changes.
To the left, it shows me the unstaged changes diff. I click-and-drag over a block of changes that I want to stage. For the purposes of clarity, I don't use any keyboard shortcut but instead right-click and choose "Stage Selection" or don't right-click but choose "Stage Selected Lines" in the upper right corner of the hunk display. Any of those three methods give the same result, but I'm not using the keyboard shortcut one to eliminate the possibility of an issue with keybindings.
The expected result is an entry in Staged Changes. The actual result is that it appears nothing happens. Also, if I then use the command line or open a different program that can read git status (e.g. Visual Studio Code or GitHub Desktop), I see no changes are staged.
At the point above where "it appears nothing happens," in Atom's developer tools the following two errors appear, both reported on <embedded>:14:
Uncaught (in promise) Error
at new GitError (C:\Users\wbt\AppData\Local\atom\app-1.58.0\resources\app\static\:14:2519366)
at C:\Users\wbt\AppData\Local\atom\app-1.58.0\resources\app\static\:14:2524504
GitError @ :14
(anonymous) @ :14
Promise.then (async)
stagingOperation @ :14
toggleRows @ :14
async function (async)
toggleRows @ :14
didConfirm @ :14
handleCommandEvent @ :11
dispatch @ :11
dispatchContextMenuCommand @ :1
t @ :1
emit @ events.js:223
onMessage @ electron/js2c/renderer_init.js:115
Uncaught (in promise) Error
at new GitError (C:\Users\wbt\AppData\Local\atom\app-1.58.0\resources\app\static\:14:2519366)
at C:\Users\wbt\AppData\Local\atom\app-1.58.0\resources\app\static\:14:2524504
GitError @ :14
(anonymous) @ :14
These errors only appear the first time I try to stage selected changes. If I reattempt to stage those or any other selected changes, the errors do not reappear. Even if I stage & unstage the whole file and then re-attempt, the errors do not reappear; only if I restart Atom and again attempt to stage the selection do those errors reappear.
When I click on <embedded>:14 to possibly see the code throwing the error, I am switched to the Sources view with a single tab labeled <embedded> as expected but it just shows a blank file with one empty line. Based on the frequency of that citation in the stack trace and the column numbers cited at the top, it looks like whatever content should be shown is minified and hard to read.
I'm on Windows 10.
When I run apm --version I get:
apm 2.6.2
npm 6.14.13
node 12.14.1 x64
atom 1.58.0
python 2.7.18
git 2.15.0.windows.1
visual studio 2017
(though when I run node -v I get v16.13.1; is that unusual?)
I would note that the prerequisites list requires checking in at https://discuss.atom.io/c/faq but this URL is blocked by a browser due to NET::ERR_CERT_COMMON_NAME_INVALID; it appears the cert is only good for *.github.com. Proceeding anyway redirects to https://github.com/atom/atom/discussions/c/faq which produces a 404 error.
The prerequisites list also requires checking 'that there is not already an Atom package that provides the described functionality' but staging selected changes is nominally part of Atom core; this is a bug report rather than a feature request.
Double-clicking to stage the whole file works as expected; file-based unstaging works too. However, that means manually undoing all the changes other than just what I want to stage, doing the file-based stage/commit, and then re-making all those changes again, which is pretty annoying.
At the moment, this is reproducing 100% of the time in one repo, even when I don't have any other Git-conversant programs (like those cited above) open. However, the issue seems to go in stretches at a time where one day it'll be doing that and the next day it'll allow staged chunks again. I have not been able to figure out the pattern of what triggers or fixes it. Also, it seems to be repo-dependent. For example, right now I can reproduce this 100% of the time in one repo and (for testing) 100% of the time in a just-cloned version of the same remote repo in a different local folder), but 0% of the time in a third. Any idea what's up?
Edited to add: The files being observed have CRLF (Windows-style) line endings. The same behavior was observed both before and after adding a repo-specific override of the core.autocrlf setting from the default true to false (then restarting Atom) as was the solution to get 'stage selected ranges' working in VSCode without having a whole-file diff. Thus, just using VS Code will likely be an OK workaround for a while, but I do think the UI and ease of staging selected ranges (when it works) is better in Atom, and fixing the issue would be beneficial for all Atom users who may encounter it.
This is an issue I've noticed on and off for a while, but has become more of an issue lately.
The following is all described from observations in Safe Mode, motivated by similar behavior outside of Safe Mode.
When I have changes to a file an I only want to stage some changes, I open the Git view and click a file listed under Unstaged Changes.
To the left, it shows me the unstaged changes diff. I click-and-drag over a block of changes that I want to stage. For the purposes of clarity, I don't use any keyboard shortcut but instead right-click and choose "Stage Selection" or don't right-click but choose "Stage Selected Lines" in the upper right corner of the hunk display. Any of those three methods give the same result, but I'm not using the keyboard shortcut one to eliminate the possibility of an issue with keybindings.
The expected result is an entry in Staged Changes. The actual result is that it appears nothing happens. Also, if I then use the command line or open a different program that can read
git status(e.g. Visual Studio Code or GitHub Desktop), I see no changes are staged.At the point above where "it appears nothing happens," in Atom's developer tools the following two errors appear, both reported on
<embedded>:14:These errors only appear the first time I try to stage selected changes. If I reattempt to stage those or any other selected changes, the errors do not reappear. Even if I stage & unstage the whole file and then re-attempt, the errors do not reappear; only if I restart Atom and again attempt to stage the selection do those errors reappear.
When I click on
<embedded>:14to possibly see the code throwing the error, I am switched to the Sources view with a single tab labeled<embedded>as expected but it just shows a blank file with one empty line. Based on the frequency of that citation in the stack trace and the column numbers cited at the top, it looks like whatever content should be shown is minified and hard to read.I'm on Windows 10. When I run
apm --versionI get:When I run
atom --versionI get:(though when I run
node -vI get v16.13.1; is that unusual?)I would note that the prerequisites list requires checking in at https://discuss.atom.io/c/faq but this URL is blocked by a browser due to
NET::ERR_CERT_COMMON_NAME_INVALID; it appears the cert is only good for *.github.com. Proceeding anyway redirects to https://github.com/atom/atom/discussions/c/faq which produces a 404 error.The prerequisites list also requires checking 'that there is not already an Atom package that provides the described functionality' but staging selected changes is nominally part of Atom core; this is a bug report rather than a feature request.
Double-clicking to stage the whole file works as expected; file-based unstaging works too. However, that means manually undoing all the changes other than just what I want to stage, doing the file-based stage/commit, and then re-making all those changes again, which is pretty annoying.
At the moment, this is reproducing 100% of the time in one repo, even when I don't have any other Git-conversant programs (like those cited above) open. However, the issue seems to go in stretches at a time where one day it'll be doing that and the next day it'll allow staged chunks again. I have not been able to figure out the pattern of what triggers or fixes it. Also, it seems to be repo-dependent. For example, right now I can reproduce this 100% of the time in one repo and (for testing) 100% of the time in a just-cloned version of the same remote repo in a different local folder), but 0% of the time in a third. Any idea what's up?
Edited to add: The files being observed have CRLF (Windows-style) line endings. The same behavior was observed both before and after adding a repo-specific override of the core.autocrlf setting from the default
truetofalse(then restarting Atom) as was the solution to get 'stage selected ranges' working in VSCode without having a whole-file diff. Thus, just using VS Code will likely be an OK workaround for a while, but I do think the UI and ease of staging selected ranges (when it works) is better in Atom, and fixing the issue would be beneficial for all Atom users who may encounter it.