> I totally disagree here; I don't think Fossil user interface is superior at all!

Have you even used it? I'm using both fossil and git and I find fossil's CLI and integrated documentation vastly susperior to git's in terms of usability.

Are you talking about the command line porcelain? If so that's certainly true, but Fossil really shines when you use its web UI as part of your VCS use cycle. And there's certainly room for additional porcelain as the repository format is a well-documented SQLite file.

Personally, I don't like either. I've found the CLI to be rather confusing, especially since there is no default SQLite filename so I can just go without having to type it all the time (that was last time I tried it).

The Web UI doesn't fare better and it somewhere on the lower half of my UX shitlist.

Fair enough on most points.

Have to point out typing the filename is unnecessary, however. Just run "fossil open" on the repository file once and from there on out any fossil command in that directory will run against said repo.

>Just run "fossil open" on the repository file once and from there on out any fossil command in that directory will run against said repo.

During my testing I never encountered that command much, though it doesn't really relieve the problem of having to double-open a repository; open folder, then open repo.

When I change a directory in Git, it automatically `fossil open`'s the current repo.

If no repository file is specified there should be an automatic fallback. Or even better, make using a non-default repo file a special flag, just like in git.

I don't really want to have to deal with opening something or connecting something when changing directories should be sufficient.

It's inconvenient for sure, but to be clear opening a repository is a one-time operation. It puts a file called ".fslckout" in the current directory which acts like the ".git" directory does for Git.