Cannot pull because there are uncommitted changes using VS2015/Git
Imagine the following scenario:
Manager has created a team project and decided to use (latest) git as VCS for the project. Developer team will be working using (latest) VS2015 (Enterprise) IDE. Manager has created a new (origin) branch called "master" and then committed & pushed 2 files to that branch.
Project file hierarchy:
Project (Root) Folder
| notes.txt
\ readme.md
Developer team made of "Jym" and "Bennie" has pulled origin/master branch (and both of them are working on local/master branch). Jym has committed & pushed the first change to "notes.txt" file (directly to master branch). Bennie has created a new file called "todos.txt", and also was making some changes to "notes.txt" file. Now when Bennie tries to sync/pull changes (that were made earlier by Jym), the following message is displayed in Synchronization window:
Cannot pull because there are uncommitted changes. Commit or undo your changes before pulling again. See the Output window for details.
To make things a whole lot worse for the team, Bennie is also experiencing the exact same issue that was opened in late December last year. This means that Bennie is practically unable to run any git command (however, all features but "undo" seems to work fine with Visual Studio Git/TFS providers - which he have found really weird).
Also because of that, this question is not (possible) duplicate of another question.
How to solve the issue (from scenario described above) that Bennie is experiencing (using only Visual Studio of course)?
If there are any more details I can provide, please just post a comment.
EDIT 1 (output from suggested answer for solving "null" device):
Results from the first step: Isn't that a typo in that answer, shouldn't "nul" be "nil"?
Results from the second step (Device Manager):
With View -> "Show hidden devices" option checked, there are no devices with small "warning" icon (unknown/unrecognized device) or "null" in any of devices' names.
Also, apparently "Non-Plug and Play Drivers" type is not even being listed (of course when View -> "Devices by type" is selected).
Results from the third step: %SystemRoot%\system32\drivers\null.sys file had existed and was deleted from the disk (copied and pasted in null.sys file from Windows 10).
More details: Once right-clicked any of those sys files, there is no "Install" nor "Uninstall" option in context menu, default action seems to be "Open with..." (which is bolded).
Results from fourth step: Attempt to merge null.reg failed. Reassigned owner of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root registry key, also set up appropriate permissions.
null.reg file was successfully merged into registry after updating registry key permissions.
Restarting a computer.
Waiting for the final answer ... Error still on show!
EDIT 2 (testing PATH environment variable):
Same error still occurs (even after opening git-cmd.exe or git-bash.exe as administrator).
EDIT 3 (power options, not using "Allow the Computer to Enter Away Mode" setting):
Reference thread.
EDIT 4:
After Bennie has upgraded his machine from Windows 8.1 to 10, issue has been solved. We can now simply conclude that operating system was corrupted.
Answer
Whenever a GUI (here a VS with Git integration) steps out of the nominal path (here a git push not immediately possible), revert to the git command line interface.
In your case, Bernie needs to a a git pull --rebase.
Open a git bash, and do (as Bernie)
cd /path/to/repo
git status # make sure everything is committed
git pull --rebase
git status # you see notes.txt as being in conflict
# edit notes.txt and resolve the conflict by removing merge markers
git add .
git rebase --continue
git push
Note, git pull --rebase might come soon to Got for Visual Studio (follow @gitforvs):
Nothing official yet though.
Regarding "Couldn't open /dev/null (or dup failed)", see if "Getting errors when using GitHub for Windows" could help (issue with the null device).
IF the error persists though, as in git-for-windows/git issue 583, re-installing Windows remains the surest way to get out of this predicament.
As mentioned by the OP OmegaExtern in Edit 4, upgrading from win8 to win10 was enough to restore the device and solve the issue.