I've been experiencing some difficulties when doing a git push to a repository on my server at home. This would occur when pushing a repository where some binaries needed updating, so there was some need for a lengthier connection than usual (the error occured at just over 20 seconds). The issue would manifest itself as a "Broken Pipe", something like this: 

Connection reset by xx.xxx.xxx.xx port 22
The remote end hung up unexpectedly, 2.40 MiB | 128.00 KiB/s
fatal: sha1 file '<stdout>' write error: Broken pipe
fatal: The remote end hung up unexpectedly

I say "something like" because actually the message was a bit garbled - probably through the stdout and sterr outputting simultaneously to the shell - and I've replaced the IP address with "x"s. 

I Googled for this problem and found enough examples of people suggesting "git config --global http.postBuffer 157286400", which wasn't relevant for me as I was using SSH. (Although I did actually try it - but as expected, it didn't help.)

Then I followed a line of inquiry based on configuring ServerAliveInterval on the client or ClientAliveInterval on the server. Neither of these helped, although at least I had the advantage of being able to control both client and server - a luxury denied most of the people that Google had turned up.

In the end, I reached the point where I was becoming increasingly convinced that my settings were OK, and decided to check if a software update was available for SSHD on my server. As I'm running a Gentoo box, this involved an "emerge --sync", and during this I got a broken pipe. So plainly there was something amiss at a networking level, and along the way the fact that I was connecting via WiFi had just become a lot less relevant, as the server is wired,and also nothing to do with the laptop. 

The laptop in question, from which I was attempting the "git push", was configured to connect to the server using its DNS name, and sure enough, the IP address in the error message was the WAN address of my outermost router; the one provided by the ISP. So I quickly added another git remote, this time using the local address of the server in the 192.168.0.0/24 subnet and sure enough, the "git push" worked like a charm. 

So now the only thing to do is figure out where this is breaking in the network. Meanwhile - if you're struggling with this, maybe your attention needs to be on something other than GIT.... and maybe not. Happy hunting!

N.B. Peter has changed the structure of the module (as he has every right to do, and I'm not complaining) - what this means is that this blog post is pretty useless other than as an exercise in poking at things. Maybe I'll figure it out, but in the meantime, assume that this technique won't work. 

I spend quite some time fiddling with various powershell implementations on my Tridion image. Whenever there's a place where I do experimental things like this, I run the risk that I'm going to break something so, at the very least, I usually do a quick "git init" in the directory, add the files and commit them. Then I have the benefit of version diffs and rollbacks if I need them. The next step comes when I realise that it's something I'm going to work on over a longer time, and that I really would prefer not to lose. At this point, I usually go on to my linux server and init a bare git, and then push from whereever I'm working.

Today I reached this second phase with the WindowsPowerShell directory of the Administrator account on my Tridion image. (It's about time, because I'm busy preparing a talk for the Tridion Developer summit in a couple of weeks, and well, losing my scripts would put a kink in my plans, to say the least.

In any case, I'd realised that I was running quite an old version of Peter Kjaer's Tridion-CoreService module. This module is the basis of pretty much any effort to use the Tridion core service from the powershell, and as this is the subject of my upcoming talk, I figured I should at least be doing my demos on the current version.

If you go to the github page for the module, you'll see that Peter's provided installation scripts which will help you to get up and running, but of course, if you have git installed, it makes just as much sense to clone the module directly. The only problem I had was that Modules are normally located in the Modules directory under the WindowsPowerShell directory. (You can add other locations to env:PSModulePath, but for what I wanted, that wasn't ideal.)

Fortunately, GIT is widely used for projects that make use of other projects, and there is very good support built in, by way of git-submodule. As my main git repository for the powershell stuff is directly in the WindowsPowerShell directory, all I needed to do was add Peter's module as a submodule with the right path.

In fact I just clicked on the menu option in Tortoise Git, but the basic command looks something like this:

git submodule add --name Modules/Tridion-CoreService git@github.com:pkjaer/tridion-powershell-modules.git Modules\Tridion-CoreService

With this in place, git understands that the Tridion-CoreService code belongs to Peter's module, and if he releases a new version, I can just pull. And of course, my own changes go in my own repository. Adding a submodule adds a .gitmodules file in your repository, so if I ever clone my WindowsPowerShell repository into another server, the location of Peter's repository can be retrieved, and the files pulled from there.

One word of warning. This is not the official release process for the Tridion-CoreService module. That is described here. As the module is pretty much a one-man affair, it's not unreasonable that there's only the master branch, so pulling from it is at your own risk. Personally I'm happy with the small risk, as it helps me to keep my development system a bit tidier - and heck - if it breaks, we'll fix it!

.

I tend to use a mix of GIT clients. Tortoise GIT is probably my main workhorse, as most of the time, managing my work via Windows Explorer is a pretty good model. Some people at the office are keen on Atlassian SourceTree, so I'll probably end up using that on projects where that's the standard tooling. Microsoft Visual Studio 2013 works pretty well with GIT, and there are plug-ins for earlier versions.

So why would I ever need a command line client, you might ask? And yet, I habitually also install GIT for Windows, (and trust me, it's not because I need another graphical client). I actually like having a command line client around, as I sometimes have the idea that some things might be simpler that way. I'm also scratching an itch to always learn a couple of ways of doing something, but realistically, I don't invest much effort in learning the command line, but I like to have it around, just in case... even at the cost of occasionally having to fend off accusations that I'm just trying to be some kind of geek..... <sigh>

And then, one day at work this week, it actually turned out that the command line was the only way to get the job done. I needed to clone a repository that was on a remote machine on a file share. Should be easy you'd think, but the remote location needed to be specified as a UNC address, and Tortoise GIT just wouldn't cope with the syntax.

So I reached for the command line, and after some cursory research it turned out what I needed to do was:

git remote add blah //SERVERNAME/c$/code/Blah

Once I'd done that, I could continue to use Tortoise, as the "blah" repository just showed up in the list...

So there you have it. I am completely justified and vindicated in keeping this software on my computers. :-) Maybe I'll practice a bit more and find some other good reasons to keep it around.

Back when Tridion Practice began in 2011, most of us were happy enough to use Subversion as the underlying version management system. Since that time, distributed versioning systems have shown their usefulness, and if I'm starting a new project these days, I generally begin by setting up a GIT repository. Tridion Practice is hosted at Google Code, and since those early days, they have added support for GIT, so it was just a matter of time before we ended up moving. To be honest, this was a bit of a dry run for moving the Tridion Power tools on to GIT. The power tools project has far more active committers working on code, so there are even more benefits to be had there. We discussed it in the team, and at first there seemed to be a consensus that it would be good to do this before SDL Tridion release their "2013" product, which will inevitably bring changes to the power tools: most likely a new branch at the least. In practice, getting a team that size all saluting the same flag is a bit more difficult, and sometimes consensus is more valuable than progress.

Git comes with some pretty solid tools for migrating from Subversion, and the Google Code support pages have a guide for migrating one of their projects from Subversion to GIT. Even with that guide, I found I had to read around the subject a bit first before having the confidence that I could follow the instructions well enough It's funny how much you come to rely on your source repository "just working", which leads to an extra bit of care in doing the migration. But, having taken that care, I can now report that the switch over went without a hitch.