SciGit, "version controlled collaborative scientific writing" launched today.

I've just signed up and created a couple of projects, and I don't get it. I was expecting something tailored towards academics to make it unavoidably easy to switch to keeping their stuff in a version control system. 
There's already GitHub, which a few academics use, but it's directed towards programmers so the complicated interface might put people off. 

It's the very first version made available, so it's understandable that it's missing most things, but I don't get where they're going with it. Here follows a big long list of complaints and thoughts.

There's a client program which handles all the git stuff. Projects created on the website automatically get cloned to a folder on your PC. You never see a git command line, which is good, but then you don't have the option to use one if you want - the SSH key for the git repo on your PC is held by SciGit so the command-line git can't communicate with their servers.

The client is currently using ~10% CPU, a few minutes after I last saved a change. Now I've uploaded my changes, it's gone idle.

A balloon pops up in the taskbar when you first change a file, prodding you to upload your changes. It doesn't appear again after that - so after a few hours of working on a document, there's nothing to stop your forgetting to upload your changes. When would you want to commit the first change you save?

scigit.com doesn't redirect to www.scigit.com (or vice versa). So I'm logged in on one, but not the other.

It's really baffling that they've concealed Git so thoroughly - it's good that they want to make a simple interface to it, but the functionality they expose is less useful even than CVS! It's currently just a Dropbox that needs constant user intervention. Most of the researchers in my department are stuck on CVS or SVN. This won't make them switch.

There's no way to merge changes, no forking of projects, no stash, and no branches. It took me an amount of lateral thinking to find out how to revert to a previous commit (right-click on a project folder, not the taskbar icon; click "Show project history", then select a commit).

Now I've reverted back to an old state, SciGit thinks my project has changes to upload. I'm not really sure what state I'm in, or what the state I reverted back from was.

Since the client is Windows-only at the moment, I can't use SciGit with my many colleagues who use Linux. They all have git installed already though - it's school policy!

The commit dialog shows you the changed files, and gives a one-line box to "briefly describe the changes made for your collaborators". It should really be encouraging people to expound a bit more on their changes - git commits allow any number of lines below the title line to add further description.
The commit dialog does a `git pull` to fetch any changes from the server before committing, which is good, but it should let me write my commit message while it's doing that. Or it could even do my commit, then pull in remote changes and merge.

There's not much point to the website at the moment. You can see your projects and manage access to them, but you can't browse their contents. You can look at individual commits, but why would you want to do that?

Projects don't have a public Git URL, as far as I can tell. So I can't point something like WriteLaTeX at it, for editing files on machines where I don't have SciGit installed.

Talking of LaTeX: all the cruft that gets generated when you compile a LaTeX document - .aux, synctex, .log files - gets picked up by SciGit for committing to the repository. This generates a change every time one of your collaborators recompiles the document. I can't find a way to make it ignore certain files. It ignored a .gitignore file I created. As it stands, GitHub is way better at recognising what language your files are written in and dealing with them accordingly.

Project names need to be unique across the entire site. Good job I grabbed "PhD Notes" early, then!

What I was hoping for was a simple wrapper round Git that makes it easy to switch to, and makes the benefits of using git clear. If they're working on making that, maybe they should've waited a bit longer before launching. For now, the GitHub desktop client does a really good job of making Git easy to use for people who don't like the command line.
Shared publiclyView activity