I’ve been using Visual Studio Code for a while now, and I quite like its integrated support for source code control (as well as the tremendous number of excellent plugins). Git is supported out of the box, and there are many third-party plugins providing support for other SCMs via a dedicated API.

So I’ve been wanting to write an VSCode plugin for Fossil; but I’m kinda despairing of ever getting around to doing that, due to the other claims on my time. Not being familiar with TypeScript or the VSCode plugin api doesn’t help.

So I was wondering, is there anyone who knows of such a plugin (I couldn’t find one on the marketplace)? Or, failing that, someone who would be able and willing to write it?

Looks like there's one started here: https://github.com/darkmusic/fossil-vscode

Thanks Joel, I hadn’t seen that one. It doesn’t look quite functional yet, but it’s more than I had. :-)

Never posted here before. Anyway, I use both fossil and git at work and have really grown to love VS Code over the past few months. Much the same as you, the built-in git integration is great and I would love one for fossil. I did see that you had started on a fossil extension but seems to have stalled. So I forked vscode-hg and got a preliminary version running as vscode-fossil and released it to the marketplace as fossil. It is still missing a lot and I haven't tested all the features, but it has what I consider to be basic functionality. I'll be using it at work and plan to release updates and new features as they come up.

I just gave it a quick spin and incomplete as it might be it seems to cover the basics pretty well so far.

Thanks a lot!

No problem!

Yeah, it works for 90% of what I want to do with it, but I would estimate that I only use about 10% of fossil capabilities, which is why I say that the extension is missing a lot of functionality.

There are also alot of other enhancements to make in terms of how well it integrates with vs code (as an example, single clicking to show a file diff in the source control viewer as opposed to to right clicking and selecting open changes).

being able to diff and merge from vs code would be stellar!

Thanks a bunch! I've checked it out, and it's workable already!

I've only run into two things that don't work so far; both in the 'version control' pane of the sidebar:

1. clicking on a modified file shows no old file, so everything shows up as new;
2. entering a commit message and pressing commit (or ctrl+enter) pops up a message 'no changes to commit' or similar

The changes in each file can be viewed inside the editor, however. And committing is always possible from the terminal, via command line — as is most of fossil’s functionality, of course.

I like that opening the 'branches' list pops up a warning when there are uncommitted changes in the working directory.

I think both of those issues should be fixed. Make sure you have version 0.0.3 installed (I think VS code would do this automatically, but I'm not sure how it handles it if you cloned the git repo)

I've made several fixes over the last couple of days, but my company blocks uploading to GitHub so it's a little difficult to push new changes while I'm at work.

I should clarify, using the commit message only commits files that you 'staged' for committing. Read the changelog for more info.

That's usually a symptom of having a Fossil binary that doesn't know where to look for its SSL CA cert DB.

That section of the docs also tells you how you fix the problem.

What platform did you see this on? The solution varies between Windows, macOS, the BSDs, and typical Linuxes.

Windows 10. Using Fossil 2.9 from fossil-scm.org

Then the plugin probably needs to include one of the cacert.pem files from my article, and have that CA cert set used by default.

Hmmm, I think I can change the way this works. I'll have to change the child process to scan stdout for prompts and then pass this to some interaction window.

Right now the child process closes the stdin stream immediately, so doesn't allow for user interaction.

No, don't just blindly answer "Yes" to questions of whether a cert should be trusted. If Fossil isn't sure that the cert can be trusted, then either:

1. The Fossil binary is misconfigured, as in my prior reply.

2. The cert is self-signed, so the user needs to be prompted to accept it because your plugin has neither the information to accept the cert on the user's behalf, nor the intelligence to apply that information correctly even if it did have sufficient information. I'm not being mean, I'm just saying your plugin isn't able to check the cert's fingerprint, call a sysadmin in site IT and hold a conversation about this on the user's behalf, etc.

3. The cert was signed by a CA your correctly-configured Fossil binary — so, not #1 — doesn't trust so it's again the user's call whether they trust that CA. (e.g. Site IT middlebox, Kazakhstan's government-mandated snoop-everything cert, etc.)

4. The cert is fraudulent, so it must not be accepted.

I agree, that's why I said I would pass the stdout to an interaction window for the user to make the decision.

I'm sorry, I somehow read your prior posting as saying that you were going to handle this warning non-interactively. In retrospect, I don't know how I got that sense from your prior reply, but that's why I responded as I did.

Not a problem. Good to see someone is checking for potential mistakes.

As of version 0.0.5 the clone command looks for stdout ending with '? ' or '?' and passes that output to an input window for the user to respond. Unfortunately the input window strips whitespace except for literal spaces so when there is a lot of output it looks pretty ugly. But it's what we have for now.

It would be really easy to add this behavior to other commands, and as I am writing this it seems like I should make this behavior for all commands. Look for a v0.0.6 I guess.

I've just tried your latest version against the official v2.9 fossil.exe, and I don't see the warning about fossil-scm.org's Let's Encrypt certificate at all, but that's because I've set ssl-ca-location to c:\path\to\cacert.pem per the docs I've linked you to above. I think you should link to that same information from your plugin home page where you talk about setting up Fossil, since this will be a common problem for Windows users.

If I unset that global setting, I do get the warning, but it's all concatenated together without the proper line breaks, and pressing Enter as it says to accept the certificate cancels the clone. Here's the tail end of the Fossil output log window:

Enabled: false, fossil clone https://fossil-scm.org/xfer c:\users\me\fx\xfer.fossil: 22401ms
SSL certificate declined
server returned an error - clone aborted

(Why "xfer"? Because I gave a different one of the repo aliases on each attempt just as a check that it's not reusing info between operations. It's the same reason my working directory is called "fx" in this iteration.)

I also noticed that the default user name of "None" causes a problem because it tries to construct a sync URL of http://None:None@example.org which almost certainly won't match any real user name and password. It should default to blank instead.

I also noticed that the default user name of "None" causes a problem because it tries to construct a sync URL of

Ah, I think I noticed that too but failed to report it. Thanks for bringing that up here, Warren. I agree that blank is a better solution.

you should link to that same information from your plugin home page where you talk about setting up Fossil

Good idea. Given the discussion about cloning, should I make a whole page about cloning and link to that from the main homepage? In that markdown I would include a link to the fossil ssl certs.

If I unset that global setting, I do get the warning, but it's all concatenated together without the proper line breaks,

In my previous comment I stated that the inputwindow in vscode strips all whitespace except for literal spaces. I tried <br>, escaping the newlines, and doubling the newlines to no avail. So the with a lot of output it looks ugly. The ways I can think to fix it are:

• Put the output in a temp file and display the temp file in the code editor for the user to respond to. Similar to running fossil commit without the -m option.
• make my own input display that doesn't strip newlines, this would have to be done outside of the vscode environment

Both of these options seem somehow clunkier to me than the ugly output (and I don't want to spend the time to do either one)

pressing Enter as it says to accept the certificate cancels the clone

It doesn't say press enter to accept the certificate, it says:

Press 'Enter' to confirm or 'Escape' to cancel

As in, press enter to confirm your input, or escape to not return an input. VSCode adds this to the prompt automatically. The last line of the Fossil output states:

Accept certificate for host fossil-scm.org (a=always/y/N)?

So hitting escape, or hitting enter with no input will pass nothing to stdin and fossil will pick it's default option, which is to not accept the certificate.

I also noticed that the default user name of "None" causes a problem ... It should default to blank instead.

Yeah, that's my mistake. I fixed in on my machine but forgot to include it in the release.

should I make a whole page about cloning and link to that from the main homepage?

I think you should delegate as much documentation as possible to Fossil itself, with your docs explaining only elements specific to your extension. Your docs should have pervasive links into the Fossil docs.

While documenting your extension, if you find yourself explaining some generic Fossil concept and can't find it discussed in the existing docs, it'd be better if you contributed the missing docs here rather than do it off in your extension's docs only.

the fossil ssl certs.

They're not Fossil's certs. It's the Mozilla/Firefox default CA cert DB, which is a convenient source of widely-trusted CA roots. It's in a format that the OpenSSL library underpinning Fossil happens to understand. All of this and more is covered in the article I linked you to above.

It's not the only possible source of CA root certs for Fossil, just a good default.

the inputwindow in vscode strips all whitespace

Ideally, you'd have a custom dialog that just displays the text output from Fossil in a <pre>, with 3 buttons below that corresponding to the (a=always/y/N) choice Fossil gives you. But, after some web searching, it looks like VSCode purposefully prevents extensions from doing that, despite being Electron-based. Annoying.

I have no better idea how to fix this than you do, but I can tell you from the end user's perspective that it is not at all obvious that I needed to type "y" in that input box before hitting Enter.

the fossil ssl certs.

They're not Fossil's certs.

I meant the fossil ssl wikipage at the certs header, which is the link you posted earlier.

VSCode purposefully prevents extensions from doing that, despite being Electron-based. Annoying.

I have no better idea how to fix this than you do, but I can tell you from the end user's perspective that it is not at all obvious that I needed to type "y" in that input box before hitting Enter.

I agree on both points, at the moment the best I'm going to do is add a troubleshooting section that states something like 'try the command on the built-in terminal if it's too difficult to understand the inputbox'.

I now have version 0.0.6 installed.

Neat, you built in support for 'staging'! I wasn't expecting that, since Fossil itself doesn't support staging explicitly (except by letting you specify file names on the commit command line; which may be what you're doing behind the scenes :-)).

But after ‘properly’ staging files first, I now get the following message:

unrecognized command-line option, or missing argument: -l

which makes sense; as per the help text, the ‘commit’ command doesn’t support -l as command-line argument. Did you perhaps mean ‘-m’ instead of ‘-l’?

But (left-)clicking on a file name in the 'Version control' side bar still results in an empty 'old' version. Right-clicking the file name, and selecting 'Open Changes' does yield the expected result. (I expected that to happen upon simple selection, seeing as that's how it works in Git and Mercurial).

Fossil itself doesn't support staging explicitly (except by letting you specify file names on the commit command line

Notes about this are in the CHANGELOG

unrecognized command-line option, or missing argument: -l

That is indeed a bug. You are committing without supplying a commit message with a message that contains non-ASCII characters, which is fine for fossil, but not for the extension at the moment. As a workaround until I can publish an update you can supply a commit message in the Source Control inputBox that contains only ASCII characters.

As far as viewing file changes: On my machine, nothing happens with a left click (single or double). I don't think anything should happen on your machine either. A right-click and select 'Open Changes' opens the changes as you describe. I'll look into making a single left click open the changes, it is a good feature to have.

OK, I updated the commit message to allow non-ASCII characters.

I also updated the input prompt to create a webview that displays the fossil output text, so it is at least readable now. You still have to write to the input window, so it's a little bit clunky but its better than it was.

Still no change on single-click to open the file diff.

I also updated the input prompt to create a webview that displays the fossil output text

Unfortunately, I think this also needs to be applied to commits.

kill.bat contains CR/LF line endings. Use --no-warnings or the "crlf-glob" setting to disable this warning.
Commit anyhow (a=all/c=convert/y/N)? a

It is applied to commits, and works correctly on my Win 10 machine and Ubuntu VM.

I haven't tried it on non-Windows yet, but what about if your files have line endings that Fossil doesn't like? Have you tried that? Oh, you also tried on Windows...hmmm...I'll see what I can figure out.

Note that allowing selection of files for commit is not the same as staging. One can see the difference by editing a file, 'stage' it, then make another edit to the file. One should see the first edit as staged and the second edit as unstaged.

Fossil doesn't have Git's concept of staging, on purpose.

I haven't been trying this plugin — I don't use VSCode in any Fossil-backed project — but if it currently talks about staging, that's a mismatch with respect to actual Fossil behavior, and it should be updated to match its interface 1:1 to Fossil affordances, not try to use Fossil underneath in terms of a Git-based UI.

Please read the CHANGELOG, v0.0.1 specifically, and make feature requests/bug reports in the repo issues.

Replying to 7:

You can diff files right now, just right click the file from the source control view and select Open Changes. And there is a Fossil: Merge into working directory... command, but I haven't tested it yet so use at your own risk.