A couple of weeks ago I started playing with Git. First of all, I love the notion of distributed version control, although it took me a while to wrap my head around it.
Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.
I found it quite hard to explain Git or distributed version control in general. The best explanation I heard so far comes from Joel Spolsky, who talked about it on the stackoverflow podcast. It goes something like this:
You are working on a local clone of the full repository and a commit is basically a set of changes applied to a version of that repository.
I have a little side-project with 2 other developers and we decided to use Git as our version control system. One of the reasons why we choose Git, was the limitations we saw in our daily work with SVN and the more important reason - isn't it just cool to try something new?
One way to let others participate in your development, is to have a repository on GitHub. Others can come in and get a local copy of your work, contribute to it and merge it back into your original source tree later on. Everything is accessible and essentially open source. However, if you pay GitHub some money, you can have private repositories with contributors - that's what we did.
The move from SVN to Git wasn't easy. We had to adopt our style of working with version control, because we ran into trouble pretty early. I guess we first needed to grok the mindset of branching and merging, before we could really leverage the advantages of distributed version control.
Unfortunately GitHub didn't help getting started. I don't know if it's because of broken tools or if it was GitHub's fault, but we managed to damage one of our branches. When I tried to pull from the branch I got the following error message:
crusty:doublemill dlinsin$ git pull origin master
error: Could not read 9b82bba67693db3b47189aefea07ec4e1d7be38e
fatal: bad tree object 9b82bba67693db3b47189aefea07ec4e1d7be38e
remote: Counting objects: 13, done. remote: Compressing objects: 100% (8/8), done.
error: waitpid (async) failed
fatal: git-upload-pack: aborting due to possible repository corruption on the remote side.
remote: Total 8 (delta 0), reused 0 (delta 0)
remote: aborting due to possible repository corruption on the remote side.
Unpacking objects: 100% (8/8), done.
error: waitpid (async) failed fatal: error in sideband demultiplexer
Since I couldn't find clear information on the problem, I decided to open an issue with GitHub support. Unfortunately after almost a week, I got a reply to my issue which was more than disappointing:
The best thing to do would be to delete the repository and recreate it with a fresh git push.
I mean seriously? Is that the best they can do? Sure, it's the easiest way out for GitHub, but not the most customer friendliest way I can imagine. It's just so disappointing, because I like GitHub and I have no problem to pay for their service. In fact, I guess I would have paid them anyways, because they have a great product and deserve some support. I just don't like this kind of "Have you tried turning it off and on again?" - attitude.
However, even after all the trouble we had, I'm still glad we choose Git. I think distributed source control is the future and I would suggest anybody to have a look at it, before starting the next project with SVN.
11 comments:
With the exception of the latest deletion fiasco on one of my repositories, I have nothing but good things to say about GitHub. Obviously, the service has its bugs, and the company doesn't do a terribly good job on the customer relations end of life, but on the whole, I think you should give it another chance. It's really hard to see the real power of GitHub until you actually play with a repository with a wide network of forks. It's really easy to see who is doing what and collaborating with who else. I wouldn't use it for a commercial project, but I can't imagine anything better for open-source.
> but on the whole, I think you should give it another chance.
I'm not giving up on it! I'm still using it daily, I was just frustrated with their support.
You make some kind of complaint without suggesting how they could have improved. What would you like to have seen them done for you? Recreate files which are corrupt or missing?
TBH, I agree with their response. For example, what can they do if the repository really is damaged? At the end of the day, the advice they gave you was sound and appropriate, and means that you are responsible for deleting any files.
I don't believe github should provide much support for git, they try pointing you in the right direction much of the time, and while I agree that their response wasn't that great from a customer service perspective, they also can't make a habit of providing every customer with git support. Next time I'd try visiting the #git channel on freenode, they are usually helpful and have got me out of a few binds.
All that said, I love git and github and hope you stick with it.
@Samuel
> You make some kind of complaint without suggesting how they could have improved. What would you like to have seen them done for you?
You know why I didn't suggest anything? Because I can't. I am just starting using Git and GitHub and I have no idea what the problem is all about. If I wasn't a paying customer, I could have lived with a RTFM kind of response.
@Rob V
> I don't believe github should provide much support for git
I guess you are right about that. However, it wasn't really clear to me if it was a problem of Git or if there was something broken on GitHub's side.
> Next time I'd try visiting the #git channel on freenode, they are usually helpful and have got me out of a few binds.
Thanks for the hint
> All that said, I love git and github and hope you stick with it.
I totally agree and I'm still on GitHub and probably will be for the near future.
Maybe you should try Mercurial. It's a DVCS like Git, but IMHO a bit more polished, thought-through and with better documentation. Since Google Code supports it now, I'm expecting more widespread adoption for Mercurial, too.
@matt
The problem is more about GitHub than Git itself. Mercurial is a fine product, but I don't think I would say that it's more well thought out. It seems weird to say it, but under the surface, Mercurial is orders of magnitude more complex than Git. That complexity bubbles out sometimes, leading to occasional bumps and bruises. Git on the other hand has an extremely simple, but intensely powerful core. Its only drawback is that it doesn't wrap that core in terms of anything that resembles a traditional VCS in more than a passing sense. In short, Git is simple, elegant and powerful, but extremely unfamiliar. Mercurial is a bit more complex, and quite a bit less powerful (rebase, local branches, etc) but much closer to SVN in terms of its interface.
@David
> You know why I didn't suggest anything? Because I can't. I am just starting using Git and GitHub and I have no idea what the problem is all about. If I wasn't a paying customer, I could have lived with a RTFM kind of response.
I'm not sure if I can come up with a suitable reply, but I do want to say something. I do understand that you might expect better support for a paid service, and if you are paying enough they should be bending over backwards for you. On the other hand, if you are not paying much for the service, than they probably can't invest much in support. In that case, they may rely on people reading documentation and doing as much as possible themselves. I've personally never had a corrupt Git repository, so I'm not sure how it has happened, but the situation you are in is quite "grey" in the sense that it might be a problem with GitHub, or it might be a problem with the way you used it. As a company, you want to help as much as possible, I would hope, but if GitHub has a significant number of people asking for solutions to problems they created, it could put a strain on their support quality, which may indeed be why there was such a delay in response.
I think ultimately it is a case of Buyer Beware - Git (the tool) doesn't come with any warranty of any kind. If it does what you want, great - if it makes your computer explode, too bad... that is just the way things are, and in that case a RTFM kind of response may be the only response that makes any sense, given the circumstances.
But, I do sincerely hope that you have found git and github to be great tools, and I genuinely hope that it works out for you. I believe that sometimes you need to use a bit of "elbow grease" or "brain juice" as it might be in this case, in order to get the most from things - some of these tools require a reasonable investment of time (and sometimes pain) in order to be useful.
Late hit, but I found this blog when running into the same sequence of issues. Coincidence implies that EGit particularly has the latent potential to break GitHub repos, as most of the folks I ran across who hit the repository corruption error are EGit users.
All unfortunate, but I agree with your conclusions. Git and GitHub have great potential and I only wish the whole ecosystem and supporting tools were a little bit more mature. Time to roll up my sleeves and contribute, I guess!
Thanks for the sympathy Rob. It was indeed EGit, which broke our repo and since we switched to command line, we haven't had any problems so far.
nice post
Quick Heal Antivirus Pro Crack
Zoom Player MAX Crack
PDQ Deploy Enterprise Crack
Post a Comment