Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

maybe: show better error msg if windows visual studio git outputs linux paths #131

Closed
binary1230 opened this issue Sep 28, 2020 · 4 comments

Comments

@binary1230
Copy link

binary1230 commented Sep 28, 2020

So, ultimately, I think this is a PATH misconfiguration problem on my end, and fixing it has fixed my issue with GitInfo.

I'm running windows 10 + GitInfo latest 2.1.2, visual studio 2019 community edition.

I installed via Nuget and got a cascade of weird errors (like not being able to find the 'System' namespace)

My .sln file was in a directory, let's call it D:\projects\project1\

The clue was this error message here:

Severity	Code	Description	Project	File	Line	Suppression State
Error		The specified task executable "cmd.exe" could not be run. System.IO.DirectoryNotFoundException: The working directory "D:\d\projects\project1\" does not exist.
   at Microsoft.Build.Tasks.Exec.GetWorkingDirectory()
   at Microsoft.Build.Utilities.ToolTask.GetProcessStartInfo(String pathToTool, String commandLineCommands, String responseFileSwitch)
   at Microsoft.Build.Utilities.ToolTask.ExecuteTool(String pathToTool, String responseFileCommands, String commandLineCommands)
   at Microsoft.Build.Tasks.Exec.ExecuteTool(String pathToTool, String responseFileCommands, String commandLineCommands)
   at Microsoft.Build.Utilities.ToolTask.Execute()	

The path is incorrect. Should be:
"D:\projects\project1\"
Instead, it's:
"D:\d\projects\project1\"

In the script, gitinfo uses git rev-parse --show-toplevel to get the path. If I run the visual studio version of git, I get this correct output:

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\bin\git.exe" rev-parse --show-toplevel

gives correct output of:
"D:\projects\project1\"

But what was happening was I had mingw64 version of git.exe (likely... incorrectly) in my path, and it was returning the unix-style path:
git rev-parse --show-toplevel output was /d/projects/project1

Somewhere in GitInfo it was attempt to marry /d/project/project1 and D:\ and produced an incorrect path of:
"D:\d\projects\project1\"

Then it all failed. Fixing my path fixed the issue and now everything's fine.


I don't know if this bug is worth trying to figure out, or if it's better to say 'silly user, please fix your busted path'.

Either way, it might be nice to at least detect the condition and either convert to a windows-style path.

Or at least display some kind of error message to give a hint about what to fix. Something like "We detected your version of git using unix-style paths, we need you to fix your PATH so it has a windows-like path".

You could do it by looking for patterns like:

"{someuppercaseletter}:\{thesamebutlowercaseletter}\" to catch strings that look like this: "D:\d\[whatever]"

Anyway, otherwise the plugin looks awesome, was just a little confused tracking down the issue as a first time user.

Thanks!
-Dom

@kzu
Copy link
Member

kzu commented Sep 29, 2020

Oh, wow, you definitely went down the rabbit hole with this one! :(

Yeah, I think the targets could check that the path separator matches the detected OS. Might not be trivial to do it in all relevant places.

Maybe you could take a shot at sending a PR?

Thanks in advance, I'll keep it open as an enhancement in case someone from the community wants to take a shot at it.

@binary1230
Copy link
Author

Ksu, if I have time, I'll give a pull request a shot that at least drops a breadcrumb pointing to the solution if a user hits this issue

Totally unrelated to this issue: I just realized I think I was using your ObservableDictionary gist in a project I was messing around with recently. Small world :)

@kzu
Copy link
Member

kzu commented Oct 6, 2020

Haha, awesome!! 😍

@kzu
Copy link
Member

kzu commented Aug 26, 2021

I was just reviewing old issues, and it occurred to me that perhaps another fix would be to add another target before SetGitExe that basically sets it to the VS-provided one if it's found, whenever you're building from within VS (by checking BuildingInsideVisualStudio=true...

@devlooped devlooped locked and limited conversation to collaborators Aug 26, 2021
@kzu kzu closed this as completed Aug 26, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

2 participants