The most usual way to work with git is to pull a local copy of the whole server using "git clone". The only way to do a partial copy would be to do a shallow copy locally with only the last few commits, but then it will probably be harder to merge back... So it seems you are either wrong, or that your team is using a very very exotic workflow.
 it is explicitly called clone and not checkout to underline the fact that you are actually replicating all the data of the server.
Going by the rest of this thread, I wouldn't rule out the possibility that they are doing something insane like committing multi-gigabyte objects regularly, and then only checking out with a low clone depth.
I've seen people attempt that before; without fail people who are deeply in centralized version control land and do not bother to understand git before attempting to switch to it (because it is trendy, or because people under them won't stop complaining about using svn in 2014).
If all your coders are editing files in one single directory all at the same time, well, that's pretty crazy. Not even CVS forces you to all work out of the same directory; it lets you check out your own local working copy and push changes to the server. Git is almost the same from the user's perspective, with the noted difference that you get an entire copy of the repo and not just one working copy of some of the files.
I see Link Bubble as an additional application rather than a complete replacement for your existing browser. Drive the Prius (Link Bubble) around the city during the week, take the truck (Chrome) out on Sundays.
Wrote a script which plays using a simple greedy approach. Chooses the current best option. Doesn't seem to get past 512 so far. It does however consistently get till 256. Just copy the code in the console and restart the game (space bar) to run.
Does anybody have a better approach? Other than randomize and trying your luck? Or maybe that is the best algorithm for this case..
More likely a header. It's 3081 byte blob after base64 decoding. If we consider it's encrypted with some block cipher with 128 or 256-bit blocks (IV and/or MAC would be likely to be 128-bit, too), there are 9 bytes for some header and/or padding.