Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Rise of Git

Soulskill posted about 3 years ago | from the git-on-up dept.

Programming 442

snydeq writes "InfoWorld takes a look at the rise of Git, the use of which has increased sixfold in the past three years. Buoyed in large part by interest among the Ruby community and younger developers, Git has been gaining share for open source development largely because of its distributed architecture, analysts note. And the version control system stands to gain further traction on Subversion in the years ahead, as Eclipse is making Git its preferred version control system, a move inspired by developers and members."

cancel ×

442 comments

Sorry! There are no comments related to the filter you selected.

It's because (1)

cameroneagans (917651) | about 3 years ago | (#36891064)

git is better than all the other VCSes

Re:It's because (1)

Anonymous Coward | about 3 years ago | (#36891104)

Git sucks unless all you're doing is merging, which is what Linus does.
Git is for small code repositories. Any of the repositories I've used professionally in the last 10 years would break git.
When git can handle 50GB+ data sets we'll talk.

Re:It's because (0)

Anonymous Coward | about 3 years ago | (#36891116)

When git can handle 50GB+ data sets we'll talk.

Break that huge repo into small, logically partitioned submodules. I think it's unlikely that any one person is going to need access to 50GB of code.

Re:It's because (0)

Anonymous Coward | about 3 years ago | (#36891462)

Correct, except for the dude who hands it all to Wikileaks or posts it on BitTorrent.

Re:It's because (1)

bmo (77928) | about 3 years ago | (#36891138)

Exactly who the fuck has 50GB in one source code tree?

--
BMO

Re:It's because (0)

Anonymous Coward | about 3 years ago | (#36891152)

Microsoft?

Re:It's because (1)

jimmydevice (699057) | about 3 years ago | (#36891548)

Snort! And most of it's dead code.

Re:It's because (1)

girlintraining (1395911) | about 3 years ago | (#36891154)

Exactly who the fuck has 50GB in one source code tree?

The answer to that question is, achem, pretty obvious.

Data, Images, Binary builds etc. (4, Informative)

syousef (465911) | about 3 years ago | (#36891286)

Exactly who the fuck has 50GB in one source code tree?

--
BMO

Those who store data, images, other binaries like built executables and other artifacts alongside the code.

You can argue that you shouldn't do that, but there are times when it's difficult to avoid, and if you need to be able to keep versions, it can be done easily with something like SVN.

I think GIT has it's advantages, but to reject all predcessors and raise it up as the only way to go is foolish.

Re:Data, Images, Binary builds etc. (3, Informative)

siride (974284) | about 3 years ago | (#36891364)

I store binary data in my Git repos and it doesn't seem to balloon as badly these days as people make it out to be.

In fact, Git seems to be good enough at it that I use it to do application releases. It's faster for me to build an app, commit it to a special Git repo and push the new commit, than to send it via SFTP over the VPN (a few hundred KB vs dozens of MB). In that repo, I have hundreds of new versions, but it's only a few hundred megabytes. The equivalent in file storage would be easily ten times as much.

I don't doubt that other VCSes do better, but Git is not awful.

Re:Data, Images, Binary builds etc. (1)

ATMAvatar (648864) | about 3 years ago | (#36891388)

Storing large volumes of binary data in an archived fashion is a job for a filesystem, not a CVS. A CVS is not intended as a backup solution, nor should it be used as such.

Re:Data, Images, Binary builds etc. (3, Insightful)

0123456 (636235) | about 3 years ago | (#36891516)

Storing large volumes of binary data in an archived fashion is a job for a filesystem, not a CVS. A CVS is not intended as a backup solution, nor should it be used as such.

So when I want to release a critical patch to an old version of our software I shouldn't just be able to extract everything from the repo, make the change and build the release installer, I should also have to find where any required binary files for that release were stored and copy them to my machine and hope that no-one deleted them in the meantime?

I really know very little about git, but from the numerous 'Git doesn't do X, Y, Z', 'But you shouldn't be doing X, Y, or Z!' posts here I don't see a reason why I would I want to.

Re:It's because (3, Informative)

bgat (123664) | about 3 years ago | (#36891190)

I'm not aware of any _code_ sets which span 50GB, and it seems unlikely that you could get to that size without a lot of machine-generated content. Such content wouldn't be ideal for git to manage, since git depends a lot on the capabilities of diff--- and machine-generated content might not diff as effectively as human-generated code. You can hardly fault a tool for doing a poorly at a job it wasn't designed to do.

Is the content you are managing that you describe as "50GB+" actually human-generated _code_? Or is it _data_? There is a big difference to git.

On the other hand, git manages the complete Android source code. It isn't "50GB+", but it is still substantially larger than the Linux kernel--- and git does fine. However, Google breaks that code base up into 150+ sub-repositories, which is actually a quite sane thing to do. I haven't tried to place Android into a single git repository, so I can't say how well git would deal with something that large. But it wouldn't be the best way to use git, anyway.

So I think your negative review of git is uninteresting, to say the least.

Re:It's because (0)

Anonymous Coward | about 3 years ago | (#36891296)

> You can hardly fault a tool for doing a poorly at a job it wasn't designed to do.

Why was using git suggested instead of other VCSes in the first place then? Of course you don't use a tool for the wrong job. The AC above simply claimed that git is not the right tool for any of the "professional repos" he used in the past 10 years.

> However, Google breaks that code base up into 150+ sub-repositories

With SVN, I never had to break up the repo into "150+ sub-repositories"

> which is actually a quite sane thing to do

It is actually the last sane thing you do because you'll become insane very quickly trying to manage 150+ repos.

> So I think your negative review of git is uninteresting, to say the least.

To somebody who doesn't *want* to hear a negative review of git, that was expected.

Re:It's because (1)

siride (974284) | about 3 years ago | (#36891354)

What's the problem with 150+ repos? What's hard to manage? How is that any harder than managing 150+ separate projects (which you have to do anyway no matter what VCS you use)?

Re:It's because (3, Informative)

wagnerrp (1305589) | about 3 years ago | (#36891418)

With git, you have no option to pull the entire repository, and all of its data, and all of its history. Aptly described by the command, you have your own local clone of the whole thing. As such, with larger projects, it becomes necessary to break the repository up into smaller, more manageable submodules. If using subversion, or some other version control system where you 'check out' rather than 'clone', it becomes possible to simply pull the current version of just the directory you want to work on. In essence each folder is automatically made a submodule.

Both strategies have their advantages and disadvantages. Every programmer is going to have their own style of work, which will be better suited towards one VCS or another. Claiming git is the perfect VCS for all occasions, as the OP did, is simply naive.

Re:It's because (1)

wagnerrp (1305589) | about 3 years ago | (#36891428)

Correction.

With git, you have no option BUT to pull the entire repository, and all of its data, and all of its history.

Re:It's because (1)

MemoryDragon (544441) | about 3 years ago | (#36891508)

Actually the repo handling is really SVNs strong side, unsurpassed by newer systems.
Externals are extremely powerful so is the simply copy paste algorithm (which internally makes hard links)
to chain together cross project source dependencies.
Git and others cannot follow that route due to their different way to treat things.
For git the server is more or less the dump to dump the files to, while for svn this is the filesystem
and the local stuff is just a small copy of what is going on on the server.

Re:It's because (2)

shadowrat (1069614) | about 3 years ago | (#36891110)

yes. it's better than everything except mercurial, of course.

Re:It's because (3, Funny)

ls671 (1122017) | about 3 years ago | (#36891404)

and saturnial is even better of course although I hear that aluminiumal is doing well too ;-)

Sad news ... Amy Winehouse, dead at 27 (-1)

Anonymous Coward | about 3 years ago | (#36891130)

I just heard some sad news on talk radio - singer Amy Winehouse was found dead in her home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss her - even if you didn't enjoy her work, there's no denying her contributions to popular culture. Truly an English icon.

Re:It's because (1)

Mad Merlin (837387) | about 3 years ago | (#36891144)

I couldn't agree more heartily. We (I) just made a clean cut over to Git at work last week (from CVS... ew), and it's the greatest thing since sliced bread.

Re:It's because (0)

Anonymous Coward | about 3 years ago | (#36891220)

More correctly phrased:

"Git sucks less than all the other VCSes"

I don't Git it.... (1)

man_of_mr_e (217855) | about 3 years ago | (#36891260)

Git has some nice advantages, especially in distributed environments.. but I still prefer svn because it's just a lot easier to use. I'm sure it's good for merging, but as a developer it ends up being a headache. For instance, if you want to check in a group of specific files and not every change you've made.. PITA

Re:I don't Git it.... (0)

Anonymous Coward | about 3 years ago | (#36891320)

Uh, how is that even remotely a hard to do? You just specify the files you want to commit...

Re:I don't Git it.... (1)

spitzak (4019) | about 3 years ago | (#36891342)

He's talking about doing a "git push" of some subset of files, not what git calls a commit.

Re:I don't Git it.... (1)

siride (974284) | about 3 years ago | (#36891374)

Then don't commit stuff to a branch you intend to push? Seems pretty straightforward to me...

Re:I don't Git it.... (1)

siride (974284) | about 3 years ago | (#36891350)

Both SVN and Git can handle only checking in a few changes, although Git has nicer tools built-in for committing only particular changes you've made (git add -p, for example). So I'm not sure what you're talking about in your last sentence.

Re:I don't Git it.... (2)

dwarfsoft (461760) | about 3 years ago | (#36891360)

My main issue with Git was it's Unicode filename support under Windows. Quite frankly it's broken. You add and commit your "Unicode Filenames" fine in Linux or Windows, but if you ever check them out under Windows they are renamed to a weird character set and require being re-added and checked in with their new path.

SVN doesn't have this problem (using TortoiseGit and mSysGit vs TortoiseSVN). I stopped using Git after I encountered this and have reverted to using Subversion until this has been resolved. If I had some time I might look into it, but seeing as it seems to be a known issue in mSysGit and the underlying cygwin(?) libraries I doubt I'd ever manage to resolve this myself without breaking something else.

Personally I like the Git Workflow, especially the commit-early-commit-often mentality that I never managed to get to in svn. It's just a shame that I can't use it seamlessly on Windows to complement my use on Linux.

Re:I don't Git it.... (1)

MemoryDragon (544441) | about 3 years ago | (#36891518)

Even as a non english speaker, I must say, don't name your filenames outside of the usual ascii range. I have yet to encounter a software project where this is handled otherwise.
If you drop the average users in things become different though, but those cannot cope with git anyway.

Re:I don't Git it.... (1)

EvanED (569694) | about 3 years ago | (#36891380)

I used to think that Git wasn't much better than SVN outside of distributed environments, but I've since changed my mind.

For instance, suppose I have local changes to my Subversion working copy, and I 'svn up', and there are some gnarly conflicts. How do you go back to the state you were in before that 'svn up'? As far as I know, you can't; you're just screwed. With git, it's easy.

Or branches. I think Subversion gets a bad rap for branching/merging difficulties, especially since 1.5, but to me the pure syntactic overhead of dealing with full repo URLs makes it a much bigger pain than it should be.

And of course you can't work on a SVN project on a plane or somewhere you don't have a network connection. (Not without Svk or git-svn.)

Or take your objection:

For instance, if you want to check in a group of specific files and not every change you've made.. PITA

I really don't know what you're talking about. At worst it's an extra command: instead of 'svn commit foo bar baz' you run 'git add foo bar baz' then 'git commit'.

At best, it's much easier, because you don't have to figure out every file you want to commit and list them all in the same command, like you do in SVN. You can change to one directory, do a 'git diff' of a file, and 'git add' it if you want the changes, then go to another directory and repeat.

And really, it's even much better than that: every tried git add --interactive? That thing is amazing. I'd pay $25 to someone if they added that feature to Subversion. (I'm a grad student and poor, or it'd be more.) That even solves the "I want to commit only some of the changes in this file" problem that I have in the past solved in Subversion by getting an 'svn diff', reverting, editing the patch file to split it up, then applying each part individually.

I really have only four complaints about git right now. (1) As stupid as it sounds, I don't like any of the workflows for setting up an initial repository. One of these days I'm going to wrap that up in a shell script so I don't have to deal with it. (2) You can't check out just a subtree of a Git repository. This actually has cost me quite a lot of time when I had to take a repository that I later figure out was too big and split it up. (3) I will occasionally get the repository into a configuration where I don't really understand how to get it back to something I know. Usually playing with it for a bit will fix it. (4) It's easy to forget to push.

Re:I don't Git it.... (2)

Chibi Merrow (226057) | about 3 years ago | (#36891408)

but to me the pure syntactic overhead of dealing with full repo URLs makes it a much bigger pain than it should be.

Try using carat (^) in a recent SVN client. If you're in a working directory, it's a stand-in for the base repository URL. so svn+ssh://foo.bar.biz/svn/widget/trunk could be written as: ^/trunk

Re:I don't Git it.... (1)

EvanED (569694) | about 3 years ago | (#36891486)

That is really incredibly useful to know. Thanks, and I'll be using that for the group projects that are on SVN.

I'll admit that I haven't kept up with Subversion for a while, because I switched to Git for my personal projects not too long after SVN 1.5 was released, but I hadn't stumbled across that one. It looks like ^ was added in 1.6, which I do have available.

Re:I don't Git it.... (1)

MemoryDragon (544441) | about 3 years ago | (#36891470)

Actually SVN has another amazing thing, you can change configurations of your project on the server centrally without filling your servers hds. You have a project 15 dependencies which change over time, simply either use svn:external, or copy them in. The next time the users do an svn:update they get all source dependencies in.
Also don't underestimate the power of the webdav support for the average user, they simply can drop the documents into their remote folders and have them versioned.
So SVN is not that bad. Git also has a load of problems especially on the command line, the command set sometimes really is awful.

Re:I don't Git it.... (1)

EvanED (569694) | about 3 years ago | (#36891526)

Git has submodules, which is at least conceptually like svn:external. I haven't used either very much (though I've used both a tiny bit) to compare or contrast in any useful way.

I'm also not so familiar with webdav.

So SVN is not that bad.

No, it's not that bad; I used it for quite some time and was pretty happy with it. (I did at one point work on a wrapper script which was going to add some features, e.g. making it's handling of svn:ignore not be retarded -- have they added recursive ignores yet?)

But since giving Git a try... there's just no going back for me. A few years ago the research group I'm in was still using CVS(now that is that bad) and there was some discussion about whether we'd switch to SVN or to Git. I had been using Git for only a little bit at that point, and I didn't have a big opinion at the time. As far as I was concerned, a CVS to Subversion switch got 95% of the benefit of a CVS to Git switch. If my present-day self was around then, I would have pushed rather harder for Git... I'd now put that at 60-70%.

I'm not saying that Git is right for everyone, but I do think that it's the right choice of the two almost all the time.

Re:I don't Git it.... (1)

MemoryDragon (544441) | about 3 years ago | (#36891438)

Well DVCs systems are different, I use CVS, SVN, and GIT day in day out, you have to work in DVCS systems differently. In SVN you have your commits thats it. In DVCs systems your commits are local and there you have control and the push is global.
So the push is more or less the final straw you have to do.
Coming from SVN you have to unlearn certain stuff.
Gits nasty side is its quirky command line, coming from SVN Mercurials workflow (which also can be built on top of Git but is not the recommended way) might be closer.

Re:I don't Git it.... (1)

ls671 (1122017) | about 3 years ago | (#36891474)

Then, what if you only want to push/commit parts of the change you made in a given file then ? The foundation of the problem you mentioned seems unsolvable.

I would say that ultimately it depends on how you organize your work. One way to organize your work would be to create branches for changes you make with each branch specific to a given bug report, change request or what not. The problem in your view would be that you will still need to merge anyways.

I think merging and branches end up being a must in most large scale project. Getting yourself a repository admin that manages the branches is usually a good idea. No need for a full time person, one of the developer or another team member can be given this responsibility.

Github? (2)

Sorthum (123064) | about 3 years ago | (#36891082)

This may be due in part to the way github integrates social networking and coding-- I'm unaware of anything similar for SVN, Perforce, Bazaar, Mercurial, etc...

Re:Github? (1)

Netshroud (1856624) | about 3 years ago | (#36891120)

Mercurial has Bitbucket, but I haven't used it much to see how it stacks up against Github.

Re:Github? (1)

Stewie241 (1035724) | about 3 years ago | (#36891150)

Bitbucket doesn't have the features that Github has. On bitbucket, pull requests are basically email notifications to the repo managers. On github, you can view changesets and now you can even do one click merging once the changes have been reviewed. There are a bunch of other features also that bitbucket just doesn't have yet. Hopefully bitbucket will improve because it will be good to have the competition to drive features.

Re:Github? (0)

Anonymous Coward | about 3 years ago | (#36891192)

Bitbucket's not too bad. No gist, but the wiki is better. Bitbucket has patch queues built in, which gihub does not, and the browseable patch queues on forks blows the doors off of github's pull requests.

Bazaar has launchpad, which seems to have a lot of features (the bug tracker is supposed to be good) but I find its UI a hopeless mess, and it's slow as molasses to boot.

Re:Github? (1)

MemoryDragon (544441) | about 3 years ago | (#36891412)

There is one thing but bucket has which is vital, they have free private repos, in github you have to pay for them.

Re:Github? (1)

Microlith (54737) | about 3 years ago | (#36891122)

Github, gitorious (we run an internal gitorious server.)

I think the fact that its primary use case is the Linux kernel has been a huge selling point in terms of its ability to quickly and reliably handle huge development communities and codebases. That it basically came to be in the very pragmatic environment of the entire Linux community also helped, as it is being used for both open and closed source projects.

All the other tools are too niche, proprietary, or were eclipsed by Git's exposure.

Re:Github? (2)

Jimbookis (517778) | about 3 years ago | (#36891136)

This may be due in part to the way github integrates social networking and coding-- I'm unaware of anything similar for SVN, Perforce, Bazaar, Mercurial, etc...

What's that you say? Social networking and Git?! Now there's an idea! I'll go set up a new site - I'll call it GitFace! Who's in with me on the IPO in 2 years?

Re:Github? (1)

Tumbleweed (3706) | about 3 years ago | (#36891164)

What's that you say? Social networking and Git?! Now there's an idea! I'll go set up a new site - I'll call it GitFace! Who's in with me on the IPO in 2 years?

And I'll create the antisocial networking version called GitOuttaMyFace, et voila, between us, we have all of humanity covered.

Re:Github? (4, Funny)

mgiuca (1040724) | about 3 years ago | (#36891214)

Well that's really what GitHub is ... much like Facebook treats every "object" (status update, photo, event) as a commentable, likable object, so does GitHub for VCS objects such as commits.

It's quite funny to see a commit with a comment thread attached to it. I saw one that went viral [github.com] and ended up with 88 comments including meme images.

Re:Github? (1)

Tacticus.v1 (1102137) | about 3 years ago | (#36891444)

Such an awesome commit :)

Re:Github? (1)

ls671 (1122017) | about 3 years ago | (#36891530)

Damn it guys, intelligent phones and what not that drive me crazy when everybody on the train look like silly ants typing endlessly on their tiny devices and now source control that integrates or offer similar functionality than Facebook ???

I am putting a hold on our upgrade from CVS to Subversion project just in case, this sounds just too scary for me ;-)

GitHub (0)

Anonymous Coward | about 3 years ago | (#36891094)

Technical aspects aside, GitHub is probably one of the most significant factors in the adoption and promotion of Git.

Bazaar (5, Insightful)

mgiuca (1040724) | about 3 years ago | (#36891126)

Yet another DVCS article that doesn't mention Bazaar at all. And cursorily swats away Mercurial as "not as large a community."

It seems like just about every argument in favour of Git could be equally applied to any other DVCS. On top of that, the only thing it has going for it is a larger community (and being the creation of Torvalds).

I've argued to wit's end that Bazaar is superior to Git in a multitude of ways (branches as separate file-system directories, optional ability to work in bound mode as with Subversion, revision numbers, explicit notion of a 'trunk' versus merged branches, explicit moves/renames rather than heuristics, commit metadata). Basically Bazaar has a much richer data structure than Git. The last point (commit metadata) is crucial: because Git lacks commit metadata, it is impossible to meaningfully use any other revision control system in conjunction with Git -- what a selfish decision.

Yet all I ever hear is "Git is better than all the other revision control systems because [generic reasons why DVCSes are better than centralised ones]." Such is the case with Scott Chacon's site Why Git is Better Than X [whygitisbetterthanx.com] , which I wrote a rebuttal of at Why Git Ain't Better Than X [wordpress.com] .

Re:Bazaar (0)

Anonymous Coward | about 3 years ago | (#36891176)

> because Git lacks commit metadata, it is impossible to meaningfully use any other revision control system in conjunction with Git -- what a selfish decision.

git-notes(1) [kernel.org]

Re:Bazaar (2)

mgiuca (1040724) | about 3 years ago | (#36891252)

From what I know about git-notes, they are a relatively new concept and aren't very well supported. Apparently they don't survive being pushed and pulled by default [nabble.com] (that's worse than it may seem -- it isn't sufficient for me to ensure they are pushed; everybody who takes a copy of the repo has to as well).

Integrating one VCS persistently with another relies on storing foreign VCS data in the metadata of the primary system -- if the primary system loses the metadata you are hosed. So for now, using Bazaar (or anything else) as a persistent Git client doesn't work, despite the best efforts of the Bazaar folks (who wrote bzr-git). I hope that one day git-notes is mature enough to support this, but it seems like it would require a backwards-incompatible change to the Git system.

Re:Bazaar (1)

m.dillon (147925) | about 3 years ago | (#36891448)

I'm not sure that repo-managed commit meta-data is necessarily a good thing, other than having the (obvious) log entry. Meta-data is so project-dependent that it is probably better to implement it as a wrapper and store it as a file within the repo instead of trying to integrate it with the repo.

Among other things, anyone who's tried to manage meta-data in repos for any length of time knows how nasty things can get when you need to edit previously committed meta-data. In otherwords, meta-data management can have far more unintended side effects then one might otherwise expect, and the result is that the meta-data management winds up locking you into a particular repo product (which is very bad).

The simpler the data management, the less tied you are to the repo.

-Matt

Re:Bazaar (3, Informative)

nschubach (922175) | about 3 years ago | (#36891178)

The main problem I've had with Bazaar is the lack of tool options. Of course, that's not really Bazaar's fault...

With Mercurial, I have tortoisehg for Windows and a very nice plugin for Eclipse. Bazaar's Eclipse integration has been rather lacking and the Windows tool chains have been slowly filing in, but it still needs time to level the field. (I'd work in Linux at work if it was an option... but it's not.) I still use Mercurial on my Linux laptop for local version management though.. mainly because it's what I use at work and there's no jumping between different keywords and methodologies.

Re:Bazaar (1)

mgiuca (1040724) | about 3 years ago | (#36891200)

I don't really use tools other than the command-line, but I believe Bazaar has had TortoiseBzr included in the main Windows package for some time now. I don't think there's Eclipse integration though.

Re:Bazaar (0)

Anonymous Coward | about 3 years ago | (#36891182)

Arguing about which DVCS is better, is just plain stupid. Let's refocus that energy to wipe subversion and its ilk off the face of our planet.

Re:Bazaar (2)

petermgreen (876956) | about 3 years ago | (#36891498)

Why? DVCS systems are great for bazaar style open source projects like linux but I don't think they are appropriate for every case. At least with hg anyone who wants to work on the code has to download the entire history of the entire repositry. That is fine if the codebase is relatively small and the users can find a fast connection for initial checkout. Not so great if you are trying to track the complete history of a large project including all the tooling needed to successfully build it.

Re:Bazaar (1)

bgat (123664) | about 3 years ago | (#36891256)

I tried Bazaar several times, and found its performance to be lacking, to say the least. Git runs circles around Bazaar for everyday commits, branching, and merging.

And I think your complaint about git's lack of commit metadata is exceedingly theoretical. Why in the world would I want to simultaneously use two different configuration management systems on the same repository? I can't believe that need would come up except in situations where one is part-way through migration from one system to the other. And git can do that just fine.

Re:Bazaar (1)

mgiuca (1040724) | about 3 years ago | (#36891314)

I tried Bazaar several times, and found its performance to be lacking, to say the least. Git runs circles around Bazaar for everyday commits, branching, and merging.

I've been using Bazaar for everything I do, large and small, for the past three years. I can't say I've ever noticed any delay in committing, branching or merging. Of course, if you are operating in bound mode (i.e., keep synchronised with the server) then it's a different story, but that's an optional feature that Git doesn't even have. From what I hear, Bazaar used to be much slower than it is now.

And I think your complaint about git's lack of commit metadata is exceedingly theoretical. Why in the world would I want to simultaneously use two different configuration management systems on the same repository? I can't believe that need would come up except in situations where one is part-way through migration from one system to the other.

Uhh, how about this hypothetical scenario: half the world uses Git. You prefer a different tool.

Seriously, it is this closed-minded thinking that I meant when I said "what a selfish decision." If everybody used Git without complaint, you would have no need for using two VCSes on the same repository. But since I prefer Bazaar, and a good portion of projects are hosted with Git, I would very much like to be able to "bzr branch" a Git repository, work with it locally as if it were a Bazaar branch, commit, then push up to the Git server. In this ideal world, we don't need to argue over which VCS is better, because I can use mine and you can use yours (just as I can use my preferred web browser and you can use yours).

Why can't we have this ideal world? Because Git lacks metadata support. The above scenario already works with Subversion. I do it all the time: I "bzr branch" a Subversion repository, commit locally, then push, and it works fine -- my colleagues who use Svn don't even notice that I used a different client. The reason this works is because bzr-svn stores its own metadata in the Subversion properties (which means that another colleague who uses Bazaar can "bzr branch" the same Subversion repository and she'll see all of the Bazaar merge history). But I can't do this with Git.

Re:Bazaar (1)

euroq (1818100) | about 3 years ago | (#36891288)

It seems like just about every argument in favour of Git could be equally applied to any other DVCS. On top of that, the only thing it has going for it is a larger community (and being the creation of Torvalds).

So, given that statement, Git is better than any other DVCS. :)

I've argued to wit's end that Bazaar is superior to Git in a multitude of ways (branches as separate file-system directories, ... explicit notion of a 'trunk' versus merged branches)

Half of your ideas really ARE better; for example a revision number is superior to a SHA not just in an opinion, but in a quantifiable way. However, branches in separate file-system directories and trunk vs merged is a superfluous way of describing the same concept, which is branches, and Git (and others) still maintains that concept.

I will argue, with both reason and experience, that separate directories for branches/trunks/tags are BAD. For example, they take up a linearly larger amount of space on your local storage media when checking everything out. Another example is that build systems can be messed up by differing directories... if you have trunk/ and branch/1 you have different levels of directories so ".." relative paths are screwed.

Having branches and a trunk is good, and Git fully supports it.

Re:Bazaar (1)

mgiuca (1040724) | about 3 years ago | (#36891398)

Half of your ideas really ARE better; for example a revision number is superior to a SHA not just in an opinion, but in a quantifiable way. However, branches in separate file-system directories and trunk vs merged is a superfluous way of describing the same concept, which is branches, and Git (and others) still maintains that concept.

Well of course Git has a concept of branches, but it only lets you access one at a time. What I find frustrating about this (besides the educational overhead of having to learn how to switch branches, and figure out which ones are being pushed and to where) is the fact that there is no URL for identifying a particular branch in Git -- URLs identify repositories, and then branches are identified by additional syntax I still haven't grokked fully.

I will argue, with both reason and experience, that separate directories for branches/trunks/tags are BAD. For example, they take up a linearly larger amount of space on your local storage media when checking everything out.

This is a common (and untrue) criticism of Bazaar. Bazaar has a feature called "shared repositories" which allows you to create a directory and say "all branches in any subdirectory of this will share revision data". The shared repo has no semantic meaning (it isn't like a Git repository) -- it's purely an optimisation to address exactly this problem. Now admittedly, it is an advanced feature that a basic user may not know about, but if you aren't using Bazaar enough to learn this feature, then you probably haven't got enough data in it to warrant this optimisation anyway.

Another example is that build systems can be messed up by differing directories... if you have trunk/ and branch/1 you have different levels of directories so ".." relative paths are screwed.

When do you ever use relative paths that go up outside the current branch into another? If you ever did that (say, a file in 'trunk' refers to "../branch"), then it would break in Git anyway, where you can't refer to another branch. I think this is a non-argument. Besides, common practice in Bazaar is to have all the branches in one directory, and also have "trunk" in the same directory (it's just another branch, that happens to be called "trunk").

Another important point: you say that "trunk vs merged" in Bazaar is equivalent to Git, but it isn't. Git's data structure is quantifiably lacking some information that Bazaar includes. In Git, when you commit a merge (say, from a feature branch to master), you create a commit object with two parents, in no particular order: a) the most recent commit on the master, and b) the last commit on the feature branch. Looking back at that commit, all you see is a commit called 0f3bc3df with two parents: 83c7ac39 and e337cb8a: you can't say which of those two parents was the previous "stable" version and which was from the feature branch. In Bazaar, in the same scenario, the parents are specified explicitly as the primary parent and the merged commit. So you would see a commit called 173 with two parents: 172 and 168.1.32 -- you know that the parent called 172 is the version immediately proceeding 173 in the trunk, while 168.1.32 was the last commit of a feature branch (and furthermore, the branch names are also stored in the commit metadata).

So yes, Git does support the concept of a master branch and other branches, but it doesn't remember, historically, which commits came from where, and thus is a poorer data structure than Bazaar's.

Re:Bazaar (0)

Anonymous Coward | about 3 years ago | (#36891352)

Bazaar is a steaming pile of manure. Your cite branches in separate folders as a superior feature? Subversion has that crap and it's messy. You also mention "revision numbers" as a feature. Who gives a crap about revision numbers? Unless you code development is pretty much linear with few, if any, concurrent branching revision numbers are meaningless. All they do is give you an obvious counter on commits.

Bazaar is like a slightly nicer rendition of SVK. Mercurial might be a worthy alternative to Git, but Bazaar is a wast of time. And I had to work with it for over a year as a developer and central repository admin. Bazaar is just plain old crap.

Re:Bazaar (2)

mgiuca (1040724) | about 3 years ago | (#36891424)

An important distinction with Subversion (which I think handles branches atrociously): In Subversion, branches are separate folders within the repository; a repository has a single linear history with branch directories inside of it. In Bazaar, branches are separate folders outside of the repository; each branch has its own history and branches are treated as separate objects. Sorry if I didn't make that clear.

As for revision numbers, on the contrary: they aren't really meaningful until you start doing non-linear history (merging). Once you start merging, it is very nice to be able to see "oh, this is revision 173 and its parent is revision 172, but it also had a merge from a branch revision 168.1.32," as opposed to Git where all you can say is "oh, this is revision 0f3bc3df and it has two parents: 83c7ac39 and e337cb8a; I don't know which one is the actual trunk history and which one is the branch commit."

Re:Bazaar (1)

MemoryDragon (544441) | about 3 years ago | (#36891362)

Bazaaars biggest problems was/is speed.

Re:Bazaar (1)

byronblue (855499) | about 3 years ago | (#36891366)

Git is the QWERTY of DVCS, I couldn't imagine using a keyboard any other way :)

Names and such (2)

girlintraining (1395911) | about 3 years ago | (#36891142)

Sometimes after spending a whole day amongst non-geeks, doing non-geeky things, I come here and read the names of some of the things these technologies are named.

Git? Ruby? Subversion? Eclipse?

I get this distinct hillbilly feeling after reading some of the names the open source community has come up with for their projects of late. Mental images of tie-clad programmers in a rusted pickup truck waving corded mice over their head while techno music plays kind of images. Then I hit page reload, and the feeling fades... until I think of Richard Stallman.

Re:Names and such (1)

PCM2 (4486) | about 3 years ago | (#36891216)

I get this distinct hillbilly feeling after reading some of the names the open source community has come up with for their projects of late.

Well, then you're a weird and obsessive person.

Photoshop? Windows? AutoCAD? WordPerfect? Dreamweaver? Flash? What kind of open source hillbilly would come up with names like that?

Re:Names and such (1)

nschubach (922175) | about 3 years ago | (#36891224)

You are complaining about the name of software projects? Have you looked at the name of cars coming out recently?

Re:Names and such (1)

girlintraining (1395911) | about 3 years ago | (#36891238)

You are complaining about the name of software projects? Have you looked at the name of cars coming out recently?

Yeah, but I can blame too much coffee and a lack of womanly affections for their market department's failures...

Re:Names and such (1)

definate (876684) | about 3 years ago | (#36891298)

Yeah, this is somewhat annoying about the *nix related culture, and sometimes they make adoption a bit harder for outsiders.

But if you think THOSE names are weird, then you haven't really used any Linux distro, have you?

The examples you've provided, aren't bad/weird names, in comparison.

"Are you running that Debian derived distro, you know, the version Obtuse Ocelot? Ubuntu, that's it! Yeah, well I installed GIMP on there, because I wanted to make an image I could share through Apache, and burn on to a DVD with XCDRoast, however I couldn't find a good sound track in my CD collection that Toaster could rip. So instead, I just dd'd /dev/random out to a file a few times, till Noatun played a reasonably nice sound. Then packaged it all up, and burnt it. It was all really easy in Gnome."

And you're complaining about Git, Ruby, Subversion, and Eclipse. Hell, Subversion is a perfectly fine name. Very descriptive, just could be a bit ambiguous "So you take the sub-version and commit it to Subversion".

Re:Names and such (0)

Anonymous Coward | about 3 years ago | (#36891410)

This is the type of "today's tech" issue that I make myself read about but always realize that it's just another part of the ether. Two days ago it was CVS, yesterday it was Subversion, and today it's Git, and as a person working in small teams (~10), or lately as a sole developer, I never saw any significant difference between CVS and Subversion despite how lauded Subversion was. So while I'm sure at some point I'll switch my projects to Git, I don't worry about it too much and focus my educational time on topics that are either more obviously needed or more widely applicable (viz., math and computer theory).

hillbillies with cultural agendas (1)

epine (68316) | about 3 years ago | (#36891466)

I get this distinct hillbilly feeling after reading some of the names the open source community has come up with for their projects of late.

There's something about "gitorious" that doesn't square with the hills of the Appalacians. You can go too far. Feynman had a point in complaining about the brethren of the elusive squirtino, which is in the news lately.

One the hillbilly side of the fence I've got a finger named "git". BitKeeper was a nice product, and a nice lesson. Thanks for all the fish may you rot in hell. After MySQL, we should have known better. Certified 100% hillbilly free by Sir Lawrence Ellison.

Also, the purple rat is not dead yet, but appears to be pushing up the daisies really slowly. Good god, it 1.0-ed when I wasn't looking! Meanwhile, the hummingbirds are feeding elsewhere.

Do your Gaga friends have culture? Of late? Just wondering.

Git is the shit (0)

Anonymous Coward | about 3 years ago | (#36891166)

'nuff said

because the others still suck (1)

quantaman (517394) | about 3 years ago | (#36891174)

I switched away from git to svn for a while since the "store the entire repository in your local project" design was killing my disk quotas, and I just didn't need all the fork/merge functionality so svn seemed simpler.

After the half dozenth time of blowing away my local svn project because something was royally screwed up again I decided to go back to git.

There's something to be said for a system that just works and doesn't end up with you spending hours screwing around with your version control system instead of getting your work done.

Re:because the others still suck (1)

euroq (1818100) | about 3 years ago | (#36891328)

I checked out the full repository of an open source project I have been tinkering with in both SVN and Git (libgdx). The SVN was MUCH larger than the Git repository on my hard drive (i think 33% more, but I can't remember). There is something else one should realize when dealing with SVN... by having more files, you are by definition taking greater than or equal to the space of less files of the same length, due to file sectors (for example, a 1 byte file takes up a whole file sector, which is 4KB on my hard drive).

On top of that, it's extremely annoying to have file duplicates in your directory. I hate searching SVN folders and importing SVN projects into Eclipse (I know, I know, you can fix the duplicate file problem, but it's still annoying).

Re:because the others still suck (1)

EvanED (569694) | about 3 years ago | (#36891446)

On top of that, it's extremely annoying to have file duplicates in your directory. I hate searching SVN folders and importing SVN projects into Eclipse (I know, I know, you can fix the duplicate file problem, but it's still annoying).

The flip side of that problem is that a subdirectory of a Subversion working copy is itself a Subversion working copy.

I actually use that a surprising amount when working with Subversion, and occasionally miss it in Git. E.g. if I want two revisions of just a portion of a repository around for a bit, I'll just copy that subdirectory. Concrete recent use case: I copied just the 'docs' directory so I could get an old version and run latexdiff.

It's not a huge win... but IMO it's not a particularly large cost to have the .svn directories sitting around, either, at least for my workflows.

Re:because the others still suck (1)

siride (974284) | about 3 years ago | (#36891476)

You can use git show and git archive to spit out individual files or directories of the repo for any previous commit. While it's one slightly extra step, it's pretty flexible and applies not just to branches, but to all commits.

Lack of tooling (2)

Luthair (847766) | about 3 years ago | (#36891180)

The lack of decent tools is going to slow adoption of git, particularly in corporations. I've yet to see a tool that can handle even a simple daily workflow so I've stuck to cli, gitk and git-gui which are all clunky. egit has definitely improved it still feels out of place and I believe is missing features (does it even support autocrlf yet?)

Corporate projects will almost certainly have a centralized repository and while git can deal with this, its possible to paint yourself into a corner where its painful to recover.

For reference, I've been a daily git user for ~16 months both at the company I work for and as a committer at Eclipse.

Tower, GitHub, GitX client (Some Mac only) (1)

SuperKendall (25149) | about 3 years ago | (#36891218)

If you are on a Mac at least, you have a number of options - Tower is a very good client, though sort of expensive. GitHub has a well written Mac client app as well (it's free).

There are other free solutions too, GitX is a pretty robust one.

I find any of these handles day to day use of Git pretty well.

Re:Tower, GitHub, GitX client (Some Mac only) (3, Interesting)

syzler (748241) | about 3 years ago | (#36891550)

Let's not forget that Xcode 4 uses Git by default and is tightly integrated into the interface. Examples being
  • * Xcode creates a git repository by default when creating a new project
  • * When saving a file, Xcode will place a "M" marker next to a file to indicate it needs to be committed
  • * Re-naming a file in Xcode will perform the rm and add operations automatically in Git
  • * Xcode allows you to view the current version and past versions side by side in the editor

Re:Lack of tooling (1)

bgat (123664) | about 3 years ago | (#36891228)

I've yet to see a tool that can handle even a simple daily workflow

You seem to neglect the possibility that the workflow itself is broken. :)

A centralized repository is a good thing for moving code between the developers and CM teams and, ultimately, on to release. But for daily development, forcing developers to all circle around a central repository a'la svn is a huge productivity killer. Git gives you the best of both worlds here.

Some of my troubleshooting gets involved enough that I have to do local commits and branching, and stashing. I'd be considerably less productive if I had to do that in a central repository. And once I have the issue resolved, git makes it really, really easy to cherry-pick the wheat out of the chaff to push into the upstream repository.

Re:Lack of tooling (1)

lennier1 (264730) | about 3 years ago | (#36891318)

Sounds all too familiar.

Last time I had to use it at a company a year ago the Eclipse integration was nowhere near the seamless integration Subclipse offers (user-friendly enough to let our graphics/layout guys use it without them having to ask us or jump through a ton of hoops because there isn't an intuitive UI).

Re:Lack of tooling (1)

MemoryDragon (544441) | about 3 years ago | (#36891382)

Corporations are always the last, there are some which drop CVS now and move to SVN. By they time the seriously consider moving away from SVN hits toolchain support already will be mature.

Re:Lack of tooling (1)

euroq (1818100) | about 3 years ago | (#36891472)

I hear you. I, almost daily, use three different tools on my Windows box for Git: GitExtensions, TortoiseGit, and the command line. I guess I occasionally use the Git+ GUI that comes with the binaries occasionally too, but only for 1 or 2 reasons that happen only once every month or two. Each of those tools can do something better than the other, and each of them also does something worse than the other.

On top of that, I work with Mac users on my team, and they only use the command line for most operations as the tools aren't available for their systems. And they tend to fuck up plenty... I don't think those guys are dumb, but I don't think they know Git as well as I do and the concepts aren't obvious and the command line doesn't make many things obvious.

Oh, and I'd like to take an off-topic moment to point out why I think *nix people are horrible user interface designers: because all *nix command line interfaces are AWFUL. They aren't easy to use, they aren't obvious, they change from one point to the next, and lots of other reasons. Git's command line has this too. Many times I hear *nix people counter with the fact that you have to be smart to use them and if you don't get it you're stupid or not as good as me. Bah! What it means is that the user interfaces suck.

A number of large external factors in adoption (1)

SuperKendall (25149) | about 3 years ago | (#36891250)

I think Git has/had a lot of things driving people that way:

1) Linus using Git of course drove a lot of Linux people to use it.

2) As others have mentioned, huge use in the Ruby community

3) GitHub, making it incredibly easy (or as easy as possible) for anyone to get started with a git project that would be hosted remotely.

4) iPhone developers, there are quite a lot of them now and many have seemed to standardize on git (in fact it's the primary SCM supported by XCode now).

Above all though I think it's probably GitHub making this all happen. Until now it was a fair amount of fiddly configuration to set up a remote SCM server, so few bothered unless you had a project with a few people and some dedication. Now I wouldn't dream about doing any project, no matter how small, without it being hosted remotely. GitHub makes it as easy as I think it can be for people who would not otherwise use SCM at all, not even locally, because they help with setup and then add the extra value of holding code safely on a server to entice you to use it.

Large, complex projects require good source contro (0)

Anonymous Coward | about 3 years ago | (#36891274)

Ok. You have a small project/sprint? Just cp your source code periodically (or rsync). You have a couple of developers on the project, use svn. But over time, the most useful projects, I predict, will be so complex that more and more code and complex algorithms will be required to _generate_ the end source code. Git is the best tool to support that for that today; and, using Git is a full skill in and of itself, a testament to it's flexibility and a warning to those in small projects trying to avoid the costs of bureaucracy.

Git's distributed design mirrors the distributed developer pool (distributed just means global--i think:p). This is why it is a natural development in code-tools. Wait. Did someone just tell me that the Linux kernel is developed using Git? (cups ear to the air)

Re:Large, complex projects require good source con (1)

siride (974284) | about 3 years ago | (#36891336)

I use Git on my project which has only one developer (me, of course). I can't imagine working without source control.

Re:Large, complex projects require good source con (0)

Anonymous Coward | about 3 years ago | (#36891356)

[...] will be so complex that more and more code and complex algorithms will be required to _generate_ the end source code. Git is the best tool to support that for that today; and, [...]

I'm curious. How would you use git to support code generation?

Mercurial (1, Insightful)

thecounterweight (2256980) | about 3 years ago | (#36891278)

hg > git > svn

Re:Mercurial (3, Interesting)

MemoryDragon (544441) | about 3 years ago | (#36891396)

Mercurial is not really superior, it is a subset of about 80% of hits functionality baked into a nicer command line set. Btw. Mercurials strong side is really the relatively clean command line outside of that both systems are so close it is eery.

You're forgetting (0)

Anonymous Coward | about 3 years ago | (#36891312)

Visual Studio rocks!!! Pwns all this stuff.

Glip! (1)

luke923 (778953) | about 3 years ago | (#36891358)

If it weren't for this (http://fimml.at/#glip), I probably wouldn't use Git. I know it ain't real Git, but it does a good job of fooling my Git client, and it lets me put up a repo on my webhost.

Winning!

Git could use revision numbers (3, Interesting)

euroq (1818100) | about 3 years ago | (#36891414)

Since the idea behind Git is that since it is distributed, and doesn't need a master repository, I guess it didn't make sense to have revision numbers when it was created (for the Linux kernel). This is because when two people make separate revisions at the same time on their local repositories, a linear revision number would conflict.

However, I've never actually used any Git project/repository which didn't have a master repository. This is both local repositories for my own projects on my Dropbox folder, and professional repositories I've used (Android and the various repositories at the company I work at), And especially at work, it has been annoying that we didn't have revision numbers.

I wish Git would get a new feature added: the ability to assign a repository as the "master" repository, and in turn the ability for the master repository to assign revision numbers. If people are wondering how that would work considering people make commits on their local repository and then push them to the master causing possible conflicts, the revision numbers wouldn't get assigned until they hit the master branch and they also split it up for merges:
      5
      / \
4.1 4.2
    \ /
      3
(or something similar to the above)

Lots of people who use an alternative VCS like Mercurial, Bazaar, etc., bitch about Git because the lack of revision numbers. To those who are unfamiliar, each commit in Git has a SHA1 hash which is used as an identifier instead of a revision numbers. Unfortunately, they are very unwieldy to communicate to others. At work we always use the name and date-time instead, but that has problems as it doesn't convey the branch for instances when it matters.

Re:Git could use revision numbers (1)

siride (974284) | about 3 years ago | (#36891436)

What problem do the revision numbers solve that tags or just using SHA1 ids (including the abbreviated ones) don't?

Re:Git could use revision numbers (2)

mgiuca (1040724) | about 3 years ago | (#36891484)

That would certainly help. I was extolling the merits of Bazaar's revision numbering scheme on my post above (titled "Bazaar"). The problem as I see it is that unlike Bazaar, Git doesn't assign any significance to the master parent of a commit. I'll shamelessly rip some text from my own explanation above:

For example, in Git, when you commit a merge (say, from a feature branch to master), you create a commit object with two parents, in no particular order: a) the most recent commit on the master, and b) the last commit on the feature branch. Looking back at that commit, all you see is a commit called 0f3bc3df with two parents: 83c7ac39 and e337cb8a: you can't say which of those two parents was the previous "stable" version and which was from the feature branch. In Bazaar, in the same scenario, the parents are specified explicitly as the primary parent and the merged commit. So you would see a commit called 173 with two parents: 172 and 168.1.32 -- you know that the parent called 172 is the version immediately proceeding 173 in the trunk, while 168.1.32 was the last commit of a feature branch.

The difference is that in Bazaar, a merge is asymmetrical: you merge from one branch to another, and it makes a difference: the "to" branch (typically the trunk) gets to keep its original revision numbering scheme, while the "from" branch gets relegated to the x.y.z scheme. In Git you merge between two branches (the order does not matter) and then commit the result to one of them (typically the master).

I would like a scheme where Git places significance on the to branch like Bazaar does, but then the Git fanatics would cry that it's possible to break things by merging the wrong way (which is certainly possible in Bazaar, but I think it's better than not having that metadata at all).

Re:Git could use revision numbers (2)

m.dillon (147925) | about 3 years ago | (#36891524)

Yes, for a git user the sha key is effectively the commit id / revision number, and it works incredibly well. I don't miss the crazy multi-dotted revision numbers from e.g. CVS, or even the simplified version numbers from svn, or anything else. The sha commit id works so well in git that our kernels include the first few digits of it in their version string printed out in the dmesg, which makes figuring out the basis for a bug report very easy.

Our use of git effectively has a master repo as well, and it is kept very clean relative to developer's local repos which have all of their local development branches.

But I think the most important feature is the utterly trivial incremental replication git supports. When we ship a new release we just include the current git repo in the disk image. If someone installs from that image they can then update their on-disk repo incrementally using the shipped repo as a base and only pull down a small amount of data over the network verses having to download the entire repo.

The incremental replication is also extremely reliable when using the git server feature (git://...), night and day compared to trying to distribute a CVS repo. My CVS repo syncnronization scripts are ridiculously complex. rsync, find the most recent change, rsync again over and over again until the repo is found to be stable and even then there is no guarantee that you have a stable copy. (and no, cvsup doesn't work too well either).

Being able to have a chain of git repos from a single master which are incrementally updated in a reliable fashion makes distributing code bases utterly trivial, and being able to ship a git repo and then incrementally update it over the net to bring it up to current is priceless. It's impossible to replicate with server-only repos.

I have no regrets switching the DragonFly project over to git.

Even dealing with pkgsrc is a lot easier in git than it is with CVS. We want to make pkgsrc available to our users but the master repo (which is in NetBSD's CVS repo) is impossible to keep synchronized using CVS, let alone be able to distribute to our user base in an efficient fashion. So what we do instead is track the CVS with a cron job and dump it into a git repo which we distribute to our userbase instead. The scripts are complex, but they work quite well and we can use the same trick of shipping out the current pkgsrc set as a git repo and have users simply do a small, simple, short, low-bandwidth incremental update to synchronize it with the latest available data.

-Matt

Git is Easy (1)

deisama (1745478) | about 3 years ago | (#36891452)

#1 reason I like Git is:
With tortoiseGit, you can right click on any folder and choose "create repository here"
And than you're done.

Its that easy

It's not perfect, but it ain't bad either... (1)

LoudNoiseElitist (1016584) | about 3 years ago | (#36891458)

So far, most of the complaints I'm seeing are developers who just don't know what they're doing. "I've yet to see a tool that can handle even a simple daily workflow..." It's called a portable Bash shell with Git, and it's amazing, especially on Windows. How hard is to commit to a Git repo? You need a tool to help you do that? Are your developers afraid of a shell? Surely not. "Until now it was a fair amount of fiddly configuration to set up a remote SCM server, so few bothered unless you had a project with a few people and some dedication." I'm not saying you're wrong (you're not) but it saddens me to think that the "typical developer" can't be bothered to set up Git and SSH on a remote server.

Eclipse has adopted Git [for] for Eclipse projects (0)

Anonymous Coward | about 3 years ago | (#36891552)

Does that mean there's a way to use git on Windows that doesn't completely suck?

My previous conclusion looking into git was that if you weren't using the command line in Linux the git developers would just as soon see you die in a fire.

Meh, call me when there's tortoisegit, and by then it will be too late.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>