java.io.EOFException: Input did not match supplied length. 2042 bytes are missing.
java.io.EOFException: Input did not match supplied length. 2042 bytes are missing.
Hi there! I’ve prepared a new version of ThinGit with drastically improved performance this time (thanks to more intelligent changes detection and push/pull behavior) and a fix for mishandled delete/modify conflict. Enjoy!
As a sidenote: if ThinGit is starting to consume too much RAM on your machine (classic behavior for Java apps) you can run it with -Xmx64m or even -Xmx32m switch. It doesn’t need any more memory – it’s just greedy Java that doesn’t want to run its lazy garbage collector.
DOWNLOAD: ThinGit Update 2012/05/24
I’ve updated ThinGit to reuse existing SSH sessions instead of re-establishing them for every operation – it speeds up processing significantly and reduces CPU usage! I’ve also made GUI a LOT more user-friendly. Enjoy!
DOWNLOAD: ThinGit Update
OK, finally I’m ready to present my collaboration/content-sharing tool – ThinGit! ThinGit periodically synchronizes local Git repositories with their remote origins and features automatic conflict resolution by creating timestamped copies of conflicted files. As such, its primary use is as an alternative to DropBox and SparkleShare!
As the name suggests, it is – similarly to SparkleShare – based on Git. To be precise – the idea behind it is identical, so all tutorials for setting up a repository for SparkleShare are also valid for ThinGit.
ThinGit is completely self-contained (requires only Java) and comes in a single JAR file 1.8MB in size. Under the hood it uses JGit (for Git repository handling), JSch (for SSH access), cli-parser (for command-line arguments parsing) and – interestingly – AspectJ. Yes – for the first time ever I actually found a good application for AspectJ. I used it to inject code that sets HTTP proxy for SSH sessions created by JGit (functionality which is unfortunately not exposed by JGit API and it wasn’t possible to set a default proxy using JSch API either). ThinGit was originally a command-line only tool (compare pics 1/2/3) and actually can still be considered command-line in nature because the minimalistic GUI I’ve prepared basically just helps you set the proper command line arguments (and remembers them for future use). To adhere more to industry standards, it also features a tray icon and notifications about repository updates in balloon tips (pic 4) but that’s it – lean and mean, as promised 😉
Now, let me describe briefly the list of parameters:
Paths containing Git repositories to be serviced – this is a list of paths on your local filesystem with Git repositories that you wish to have handled by ThinGit
HTTP proxy host/port/username/password – these parameters specify the HTTP proxy to be used; if host is not set, the others are ignored
Username to be used in case of interactive authentication – CLI-only – specifies the username to be used for remote SSH connections
Ask for password to be used during interactive authentication – CLI-only – makes ThinGit ask for password at startup; this password will be used for all authentication purposes later
Delay between synchronizations (in milliseconds) – Delay between consecutive cycles of synchronization; it’s a matter of personal taste, reasonably can be anything between 10 seconds and 10 minutes; note that if both sides have this delay set to 10 minutes, the worst case delay between side A updates getting propagated to side B is 20 minutes!
Disable graphical subsystem – forces use of CLI; normally ThinGit tries to launch GUI and only if it fails, falls back to CLI
Clone selected repository – this argument takes precedence over -repos; if it’s specified ThinGit will perform a git-clone command on the selected repository; normally you will launch ThinGit once with this parameter set and then clear it and set -repos instead
Target path of cloned repository – target argument of the git-clone command
Cycle once through repositories and exit – don’t loop the execution, process all repositories once and exit
Show configuration dialog – Unused
Set Java look and feel – GUI-only – Sets Java Look and Feel, possible values are windows and gtk; you can also set LAF using Java’s standard -Dswing.defaultlaf= switch. Requires restart!
Start as tray icon only – GUI-only – Starts application without showing the main window
Noteworthy, JGit, and thus ThinGit processes ~/.ssh/config file so it is possible to set up a password-less key-based login to your repository server! In my case, the whole setup was like following: I’m running an Apache server with mod_proxy limiting access by IP and AllowCONNECT set to Yes and SSH with key-based authorization. My ~/.ssh/config contains appropriate entries. My key is password protected so I have to enter the password each time ThinGit starts. I configured proxy first giving algoholic.eu as host and 80 as port, then I ran ThinGit with -clone set to algoholic.eu:/tmp/git1 (my test repository) and -clone-dest set to C:/tmp/git5. After it completed cloning, I ran it with -clone parameter removed and C:/tmp/git5 added to -repos.
And that was it! Now I have it running on my test repository for 24 hours already and it’s doing nicely so far. It’s doing such a good job replacing my pen-drive that I’m actually going to establish a more permanent repo and hold all my small projects together in there. I was growing tired of creating separate Git repos for each small thing and keeping them without any versioning is also quite bothersome, so I welcome my own new creation 😉
As you can see (pic 5) a repository serviced by ThinGit can still be accessed by regular Git tools (in this case – GitExtensions) allowing for easy history management.
To summarize the rationale and benefits of ThinGit:
1) Self-contained Java-based application – just one small JAR file for every platform (also Windows XP 😉 ) supporting Java SE. It’s by far the smallest application of this kind!
2) Supports HTTP CONNECT proxy – in my experience, the most reliable way of circumventing firewalls (SOCKS proxy are supported using Java’s -DsocksProxyHost=socks.mydomain.com switch)
3) Command-line and graphical interfaces that map almost 1:1 allowing for execution in environments with or without graphical subsystem.
4) You can use existing Git tools, including Git-based sharing/collaboration applications like SparkleShare in an interchangeable manner (e.g. when you need to access your repository from Android, SparkleShare might be the right choice!)
5) And of course this – part 1, part 2
I recommend ThinGit to those who are concerned with security and for some reasons have trouble running SparkleShare or just like a lean-and-mean solution like ThinGit more. Enjoy!
DOWNLOAD: ThinGit (JAR file inside ZIP)
As announced, I’ve installed DropBox and SparkleShare today on my Windows XP-based PC. DropBox works out-of-the-box 😉 and makes the impression of a mature and stable application. It works fast, reliably and features Web interface to overlook and manage the state of your remote repository. Its only shortcoming (except for the one mentioned in previous post) is that you cannot manage file history in off-line mode – this is something Git-based solutions for sure don’t suffer from (major benefit of distributed VCS). Thanks to directory monitoring, changes are picked up right when they actually happen (not in a time-triggered fashion) and are propagated to DropBox server almost instantly. So basically – DropBox just works(tm 😉 )
Now to SparkleShare – unfortunately, I’ve learned the painful way (immortal ‘Program has ended unexpectedly…’ message) that it is unsupported on Windows XP !!! That’s a major issue in my opinion but never mind – I gave it a try anyway on another PC running Windows 7. SparkleShare’s user interface looks quite nice and provides easy wizard-based configuration. We can have SparkleShare handle Git projects hosted on our own server or any of the free Git hosting providers: Bitbucket, Github, Gitorious or The GNOME Project. However, all seems nice and well only as long as you’re not behind a firewall! I’ve tried to add a project hosted on my own server and failed miserably. For all the free hosting providers SparkleShare also tries to use SSH and fails. And there’s no option for HTTP proxy configuration (this is what I normally use to punch through to my server). Ouch! That’s painful – I can’t really test it now, can I? ;/ Actually I can but since it requires some extra steps, I will let it rest for now.
It was all anyway to prepare the stage for a new player – my very own thin-git ; ) More about it in the next post. It actually works where SparkleShare failed! 😉