Skip to content
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

View History window says "This repository does not yet contain any commits" #6343

Closed
tpulokas opened this issue Mar 4, 2019 · 13 comments · Fixed by #6477
Closed

View History window says "This repository does not yet contain any commits" #6343

tpulokas opened this issue Mar 4, 2019 · 13 comments · Fixed by #6477

Comments

@tpulokas
Copy link

tpulokas commented Mar 4, 2019

Current behaviour

From the File Tree, I double-click on a file or right-click and select "View History". The "File History" window opens, but it says "This repository does not yet contain any commits".

The same thing happens in most of my repositories, although there are a few repositories where the "File History" does show me the history and blame as expected. The repositories where it works as expected all seem to have a small number of commits and only one branch. However, my screenshot shows one example of a small repository with one branch where I experience the problem.

Expected behaviour

The window should show history and "blame" information.

[EDIT]
The fix involves removing duplicate slashes from repository paths.

Steps to reproduce

Open repository
In File Tree, double-click on a file

Screenshots

gitextensionshistory1

Did this work in previous version of GitExtensions

I have successfully used the "View History" window, often for the "blame" tab, many many times over the years. I noticed the problem today in version 3.0.0. I upgraded to version 3.0.2 and I still have the problem. I do not recall if I ever used "View History" successfully in version 3.0.0.

Environment

  • Git Extensions 3.0.2.5232
  • Build 23b6f51
  • Git 2.20.1.windows.1
  • Microsoft Windows NT 10.0.17763.0
  • .NET Framework 4.7.3260.0
  • DPI 96dpi (no scaling)

Diagnostics

@RussKie
Copy link
Member

RussKie commented Mar 4, 2019

Curious, why does you path contain double slashes?

@gerhardol
Copy link
Member

I cannot reproduce.
Have not seen this in any version. I tried creating a minimal repo if this was related to only one version of the file, but no luck.

Can you try the GE repo (or some other public repo) to see if it is your environment?
If not, can you share the repo?

@tpulokas
Copy link
Author

tpulokas commented Mar 4, 2019

Curious, why does you path contain double slashes?

I have no idea why the double slashes are there. I think you have found something though. Out of about 20 repositories on my GitExtensions dashboard, it looks like about 3/4 of them have those double slashes in the path. It seems like the repos that have double slashes will have this problem with "View History", and those that have normal slashes will not have the problem. I don't think the double slashes were there before.

@tpulokas
Copy link
Author

tpulokas commented Mar 4, 2019

can you share the repo?

I would be happy to share the repo, although I don't know the procedure for sharing.

It looks like there real question might be why there are double slashes in the path?

@gerhardol
Copy link
Member

I would be happy to share the repo, although I don't know the procedure for sharing.

Like putting it on GitHub. But if this only occurs on repos with '\', probably no need.

How do you open the repos?

@tpulokas
Copy link
Author

tpulokas commented Mar 4, 2019

I did an experiment. I picked a repo that had the double slashes, and verified that it had the problem with "View History". I found the file "GitExtensions.settings", wherein I used a text editor to turn the double slashes into single slashes for that repo. When I re-opened GitExtensions, "View History" works as expected for that repo.

@tpulokas
Copy link
Author

tpulokas commented Mar 4, 2019

How do you open the repos?

I always open GitExtensions from a QuickLaunch shortcut. Then I double-click the repo in the dashboard.

Now that I think about it, the repos with the double slashes are probably carried over from the dashboard in GitExtensions version 2.51. The ones that had single slashes were probably new that I added after upgrading to version 3.0.0.

@tpulokas
Copy link
Author

tpulokas commented Mar 4, 2019

I did another test by putting double slashes back into "GitExtensions.settings" for the repo that was working correctly. After re-opening GitExtensions, this repo displays the problem with "View History".

I have now converted all double slashes in "GitExtensions.settings" into single slashes. As far as I can tell, my problem is resolved. Thanks to all for your help!

@RussKie
Copy link
Member

RussKie commented Mar 5, 2019

If we could establish how you got \\ in your config we could possibly attempt to fix it.

@gerhardol
Copy link
Member

If we could establish how you got \ in your config we could possibly attempt to fix it.

  • The path could be checked when opening (is not this changed in master already?)
  • Quoting when opening file history need to be investigated

@kltk
Copy link

kltk commented Mar 6, 2019

same quastion with relative repo path

@tpulokas
Copy link
Author

tpulokas commented Mar 6, 2019

If we could establish how you got \ in your config we could possibly attempt to fix it.

I'm sorry that I don't remember exactly what happened with my GitExtensions dashboard. I think maybe when I upgraded to version 3.0.0, all of my dashboard's "Favorites" and/or "Recent repositories" were lost--I think I remember being frustrated by that. I might have copied all those paths into the dashboard one-by-one. Therefore, it's possible that the double-slash was some artifact of whatever I used as the source of copying.

I did a little test just now in version 3.0.2. From the dashboard, I clicked "Open repository". In the "Open local repository" dialog box, I pasted a path that had double slashes. The double slashes then remained in the path of the repository, including in the link on the dashboard. So I can suggest that GitExtensions would proactively turn such double slashes into single slashes. Perhaps this would prevent everything that went wrong for me, but I'm sorry that I can't quite remember how I got there, and I hadn't noticed the double slashes until you pointed them out.

@RussKie
Copy link
Member

RussKie commented Mar 6, 2019

when I upgraded to version 3.0.0, all of my dashboard's "Favorites" and/or "Recent repositories" were lost--I think I remember being frustrated by that.

Sorry to hear that. This doesn't sound right, they should have been migrated.

@RussKie RussKie added type: bug 🐛 up-for-grabs Easy tasks for those looking to get involved. Refer to https://up-for-grabs.net/ status: workaround available and removed status: more info requested labels Mar 6, 2019
@RussKie RussKie added this to the 3.1.0 milestone Mar 6, 2019
RussKie added a commit to RussKie/gitextensions that referenced this issue Apr 16, 2019
It was possible to add a working directory that contains double slashes,
and this breaks certain functionality, such as viewing file history.

To prevent this, a working directory path is normalised when a new
instance of `GitModule` is created.

Fixes gitextensions#6343
@RussKie RussKie removed the up-for-grabs Easy tasks for those looking to get involved. Refer to https://up-for-grabs.net/ label Apr 16, 2019
@ghost ghost assigned RussKie Apr 16, 2019
@ghost ghost added the status: ready label Apr 16, 2019
RussKie added a commit to RussKie/gitextensions that referenced this issue Apr 16, 2019
It was possible to add a working directory that contains double slashes,
and this breaks certain functionality, such as viewing file history.

To prevent this, a working directory path is normalised when a new
instance of `GitModule` is created.

Fixes gitextensions#6343
@ghost ghost removed the status: ready label Apr 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants