I'm using Rubberduck (Version 2.0.13) in combination with a local git repository for version control of my VBA project.
Currently, I need to re-open the repository every time I start Rubberduck using Manage -> Open Existing Repository
in the Source Control Window.
Is there a better way to handle the local repository, e.g. can Rubberduck save this setting? I don't want to use an online repository, so I think the "Unsynced commits" tab is irrelevant for me.
This started as a comment, but got too long... so I figured I'd make a disappointing answer instead.
I don't personally do much VBA (lately anyway) so I can't say I actively use Rubberduck's source control feature, and I haven't really contributed much to that part, but I know users that seem to manage to use it - with both local and remote repositories: these users can probably give you a better answer than I can as far as using it goes.
There are quite a number of open issues involving the source control feature, even a project dedicated to stabilizing it. Basically it's provided "as-is", as in "better than nothing".
The idea is that it's supposed to pick up the ProjectId
(which we're currently storing in the write-enabled VBProject.HelpFile
no-one-ever-uses-that property - you want to confuse the heck out of Rubberduck you just change that value) of the active project, after we've parsed it, so we're sure the project has an ID when we look in the %appdata%\Rubberduck\SourceControl.rubberduck
file to see if that project ID is associated with a known repository - and if that's the case, then we'd open that repository and update the SC panel.
The configuration file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<Configuration>
<SourceControlSettings>
<UserName />
<EmailAddress />
<DefaultRepositoryLocation />
<Repositories>
<Repository>
<Id>86689642</Id>
<LocalLocation>C:\Dev\VBA\VBTools</LocalLocation>
<RemoteLocation />
</Repository>
</Repositories>
<CommandPromptLocation>cmd.exe</CommandPromptLocation>
</SourceControlSettings>
</Configuration>
We are storing the information - the repository <Id>
should be used exactly for this, so either it's working but not reliably, or it was creating problems and was disabled.
But you are correct: having to manually open the working repository every time isn't an ideal UX. Whether there's a remote or not shouldn't make a difference, you still need to have a local copy when you have a remote.
I remember at one point it was debated whether we should let the user browse for repository location, or just list the known repositories from the configuration file - it was decided that letting the user browse and open any git repository known to Rubberduck or not, would make it much easier and flexible, especially when no repository is known to Rubberduck yet; feel free to open an issue on GitHub if you have ideas or feature requests (or just to report a bug).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With