tekkub

Thanks for the feedback. We try to at least get a reply to everyone, could you forward me the email so I can see if I can find it? [email protected]

I'm sorry you feel my replies were hostile, but I don't really understand why. Here's the timeline of your two emails:

September 02, 2011 @ 09:49 PM you opened the initial bug report

September 03, 2011 @ 08:06 PM you opened the second

September 03, 2011 @ 08:45 PM I responded to the first (we work from the oldest to newest). This was my reply:

> Thanks for the report. This is a known issue, we have a ticket open to get it fixed.

I continued to work through our inbox, 20 minutes later at September 03, 2011 @ 09:04 PM I hit your second ticket. That was for the same issue, with a little extra info. I replied with:

> As I noted in the other thread, this is a known issue, we have a ticket open.

I honestly don't see how these replies were hostile in any way. I thanked you for the report, I told you we had a ticket open to fix it, and then I acknowledged the second one so you'd know that we received it.

I'm open to any suggestions on how you'd have handled this differently.

I assume you mean `git push origin :featureBranch`? Deletes a branch pointer on a remote repo. No data is lost, it just takes a little effort to dig it back up if you don't know what SHA the branch was at.

I find the "too easy to break the repo" argument really quite odd. While I understand why users think this is true, it's actually very far from the case. The git repo is very stable, has built in error checking, and is extremely stubborn about removing data. The working copy on the other hand, is very easy to jack up if you're not sure what your commands are doing.

The best thing you can teach someone just learning git is to commit very frequently. If your files are committed, you can undo most any error. But if you've got a dirty working copy, you could lose it if you do something drastic. As an added bonus, this also teaches the user to branch often, and eventually they'll find the majick of `git rebase --interactive`

The collab limits aren't soft, they're just not strictly enforced right now. We may start enforcing them at any time.

To add to this, we don't strictly enforce the limits (hence the liberal use of the word "soft"). We aren't going to lock you down if you go over the limit, so why does it matter? The limit is there to help you more than anything, if you're hitting it something is wrong somewhere.

There will always be people that don't like what we do, no matter what we do. Drink? Someone will hate us for it. Act like professional business executives, someone will think we take ourselves too seriously. I think the trick is to find the right balance for our target market, and I think the guys are doing quite well at that. I don't think any of us expect to pick up big businesses for Firewall Install at meetups, we're going to get those customers by way of developers that are already using git, and from the talks we give about git and GitHub at places like Yahoo. If all people see is us drinking every other Thursday, they're missing a lot.

Customers complaining about performance certainly have a valid point. But if they believe that these issues are caused by a lack of dedication or just general "goofing off", I think they're mistaken. Frankly, Tom's been working his ass off since April with the Rackspace move. At the same time, Chris has focused nearly all of his time into keeping the site up as is and doing everything he can to maintain or improve performance with the hardware we have. There's simply hardware bottlenecks blocking our way at the moment. I'm sure everyone knows my feelings about GFS by now.

Proof certainly is in the pudding, and I think everyone is going to love the pudding we'll be serving up from Rackspace. I know it's hard to be patient and wait for the move to happen... trust me I really do. I'm the one on the front line every day with unhappy customers who have to deal with the latency and job queue backups. I don't think there's anyone that wants the move to happen more than me.

People notice, but only to a small degree. When I was out in SF back in July I didn't intend to drink much at the meetup. I think I had 4 drinks total, all were bought by someone else for me. If I had declined the drinks, or gotten something non-alcoholic instead, I doubt anyone would have made a fuss about it.

Well.. and PJ did shove like $15 in the jukebox and demand I pick songs, and gave us money for the taxi ride home which also paid for a nice pizza back at the hotel.

As are we, disk space should never be an issue with us unless you're doing something very wrong (hosting videos, etc).

Branching was by and far the winning feature for me. SVN made branching and tagging very time consuming (making a full copy, to the server nonetheless). Merging correctly on SVN? Never the first time! Usually took 2-3 tries before you got the syntax correct. Dry-run never really helped either. SVN merging was leagues harder to learn then the entirety of git for me.

The simplicity of making a local directory versioned is wonderful too. It has use far beyond code. I can quickly version my documents folder, easily recover from mistakes, and with one little push I have a backup! To even try to do this in SVN was another headache, and it required an SVN server somewhere... with git I don't have to push if I don't want to.