Git Adoption Soaring; Are There Good Migration Strategies? 346
Got To Get Me A Git writes "Distributed version control systems (DVCS) seem to be the next big thing for open source software development. Many projects have already adopted a DVCS and many others are in the process of migrating. There are a lot of major advantages to using a DVCS, but the task of migrating from one system to another appears to be a formidable challenge. The Perl Foundation's recent switch to Git took over a year to execute. The GNOME project is planning its own migration strategy right now after discovering that a significant majority of the project's developers favor Git. Perhaps some of the projects that are working on transitions from other mainstream version control systems can pool their resources and collaborate to make some standardized tools and migration best practices documentation. Does such a thing already exist? Are any folks out there in the Slashsphere working on migrating their own project or company to a DVCS? I'd appreciate some feedback from other readers about what works and what doesn't."
Git links (Score:4, Informative)
Re:Git links (Score:4, Interesting)
FTR I love hg, and I see no reason to switch to git, even though the whole bandwagon movement seems to have jumped on the git train.
Re:Git links (Score:4, Insightful)
If you love Hg, there are no strong reasons to switch to Git. None whatsoever. In the same coin, if you love Git, there are no strong reasons to bother switching to Hg, either. Both are *really good* at what they do, and they do it very well. Unlike, say, SVN, which really is for the i'm-too-dumb/lazy-to-use/learn-something-better crowd.
And it is *trivial* to learn to use both git and Hg at the same time if you already know one of them, so you can work properly on projects that use either one without much fuss.
That said, git is evolving a lot faster than Hg. Which could be a reason to either avoid git over Hg, or to avoid Hg over git, depending on your own view of such matters :-)
Re:Git links (Score:5, Insightful)
Unlike, say, SVN, which really is for the i'm-too-dumb/lazy-to-use/learn-something-better crowd.
I'm part of the "SVN is working just fine" crowd. If you want people to switch, being a condescending asshole is generally a great way to prevent that and make them more entrenched.
Frankly, no one, including yourself, ever mentions a reason WHY I should switch. I think you should eat pickles for breakfast! Why? *silence* ... dumb ass.
Until this article, I didn't even know it was a distributed system. I'm still not sure why I should care. I haven't cared enough to look into git because I'm busy, my time is important, and SVN works flawlessly for me. As far as I know, you're just the type of person that needs a high performance sports car to drive back and forth to work.
So, the next time you're trying to convert people to your new religion by calling them imbeciles, you might want to consider throwing in at least ONE selling point before your vanishing attention span drags you off to a new shiny. K? Thx
Re:Git links (Score:5, Informative)
In case you were looking for answers rather than abuse: I have used both. For me git does what svn does, plus the following in order of most important first.
Of course, this is for me, and all points might be irrelevant for you.
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
I can give you the reason why I switched.. which may or may not help.
With SVN, I found that branching was so involved that I wouldn't do it. Instead, I would check out code, work on it, and wouldn't check it back in until I had completed whatever I was doing... which may be days or weeks away.
Checking code back in with SVN almost became a "release".
With Hg, I pull down a copy of the code, make changes, commit those changes to m
Re: (Score:3, Informative)
Ignore tha fanboys. If anything, use them as statistical evidence that there might be something worthwhile here. :-)
Why git for a SVN user? There's nothing better than trying it for yourself (git-svn clone svn://whatever, then hack on it with git, then git-svn dcommit). But until then, two big points:
1. It's distributed. I can make lots of commits without pushing them somewhere public, which is good for the same reasons that hitting "Save" often is good, without being worried that I've broken the build for
Re: (Score:3, Interesting)
Well subclipse was started by a single person wanted to have a decent svn plugin it took the guy more than one year to get to a working level, so it takes time.
Git would be the perfect companion for eclipse, it could replace the local history and the remote version control system but that would mean a proper integration of GIT might be 10 times as complicated because it has to replace both version control subsystems eclipse has.
Also git has several unresolved issues, how are you going to do a server repo br
Re: (Score:3, Insightful)
The right way to do it, at the photo editing side, is to keep the original photo and define a file format for the edits. *Then* VCS would make sense for them.
Re: (Score:3, Insightful)
A source controls systems PRIMARY function is to keep track of how things changed over the history of a project.
So if you have a project that contains binary files like photos as well as code it makes sense to choose a version control system that can handle both at a tollerable speed so they can be versioned together.
P.S. I can think of ways to merge changes in images so if your vcs allows you to hook in custom merge tools you could probablly add image merge support (whether the results would be what you wa
Re:Git links (Score:5, Informative)
Some things git is bad at:
- no of partial cloning, so a big history means lots of stuff to download, this is especially bad when it comes to binary files
- no way to download just a single file or directory, a user always has to clone the whole repository
Re:Git links (Score:4, Informative)
For problem one: git clone --depth 1 (or however far back you want your history to go); note this severely cripples git's abilities and isn't very useful at all unless you're on dialup still.
For problem two: this isn't a real problem with git, but rather with your organization. Multiple projects don't belong in the same repository, it's as simple as that.
Re:Git links (Score:5, Informative)
Problem two *is* a problem with git, it has nothing to do with how you organize a project, since you can never guess what a user might want. Simple example: I would like to look at the latest version of a file in the linux kernel, with git I have to download the whole beast when all I want is a single file, which is neither pretty nor fast.
Re: (Score:3, Interesting)
Re:Git links (Score:4, Informative)
I hadn't really thought of that, I had assumed you were referring to Subversion's rather common case where multiple projects are stored in the same repo, and you checkout different directories to access one of them.
Anyhow, most, but not all, public git servers have a gitweb or similar attached, which will at least let you browse and download files from the tree if you need to. For example, grabbing the latest README of Linus' Linux tree can be had via http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=README;hb=HEAD [kernel.org]
Git itself doesn't provide any mechanism for it, however, but it's fairly unusual to be interested in a specific file rather than the entire project.
Git providing access to the latest files (Score:4, Insightful)
You're quite right. It seems to me that Git isn't intended to provide access to the latest versions of individual files. Git, like all DVCS's I know of, is essentially a version-control plugin for your filesystem. The filesystem itself provides the current version you're working with, and so it's only a matter of providing an http server over the directory or something like that. Which is exactly what GitWeb and Trac-Git provide, only they're better.
Re: (Score:3, Interesting)
Except if one is simply reviewing a specific file or files - for a code review, debugging, or copying pieces to another project. I do this all the time when helping others on their projects. I don't need (or want) the whole hot-mess...
Re: (Score:2, Informative)
Unless you are intensely involved in a project, browsing for the single file using some alternative interface is probably going to be easier. I.e.:
http://github.com/github/linux-2.6/tree/master/kernel/fork.c [github.com]
That doesn't work if the repository doesn't have an alternative interface though (but for projects you are involved in, the download only needs to be the difference between the internal and external repositories, not the entire history).
Re:Git links (Score:4, Interesting)
For problem two: this isn't a real problem with git, but rather with your organization. Multiple projects don't belong in the same repository, it's as simple as that.
I have been wanting to start with Git, but I find it too hard to know what should go into different repositories and what should be in the same.
First example: I might be writing a book in book/ and keep all images in a subdirectory book/images/. I think it is not far-fetched that I might want to work on only the images without downloading all the other, possibly huge, subdirectories.
Second example: Say I write a scientific article for which I compute a lot of numerical data. Then I write a second article, which builds upon the same data. Should the two articles go into the same repository, so that I can easily pull and compile everything at once with all dependencies in place, or should they be kept separately, so that I can work on the first article without dragging the other one along?
Re: (Score:2)
If your needs are so drastic, just split it into multiple projects for each team. You can tie them all together via submodules to make a meta-project git to clone when someone really wants it all.
Really not an argument against git, you're just not thinking hard enough.
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
Some of our submodules are 20 times bigger than the Linux kernel and there is no way to subdivide them more than that.
But do they accept more changes than the Linux kernel does? Linus Torvalds's 2.6.28 tree alone (which goes back to 2.6.12-rc2, dated April 16, 2005) has 120035 commits. That doesn't include any branches that others have worked on.
Re: (Score:3, Insightful)
Sorry to burst your bubble but most software projects do involve artwork and it makes a lot of sense to version that, too - along with the source code.
Do you think artists never make mistakes? Do you think nobody ever wants to go back to an older version of a button-image after a while because the new one wasn't received well?
Well if so then let me welcome you to the real world.
Re: (Score:3, Interesting)
I'm a Bazaar fan. That isn't to say I'm not a Git fan, I just prefer Bazaar (by a small margin, for a handful of reasons).
That website makes a really good case, but I think they should remove "Bzr" from the "Cheap Local Branching" section. I could s/git/bazaar that entire section and it would still be almost correct.
Bazaar has a totally different view of branches, but it gives you all the same flexibility as Git. The only thing is that Bzr branches are full copies of the entire repository - so they aren't "
Meanwhile... (Score:5, Funny)
(shit).
Comment removed (Score:5, Informative)
Re: (Score:3, Funny)
How to identify managers promoted beyond their capability?
They recommend, or worse, force a migration to Clearcase; usually based on lies about the existing solution to their management.
Re: (Score:2)
Re: (Score:2)
The solution to clearcrap is a baseball bat
I swear to God, last time someone suggested Clearcase at my job I said "OVER MY DEAD BODY"
Re: (Score:3, Insightful)
Re: (Score:2)
I agree, this reminds me of that false-myth: "USA spend $1M in a pen that work in space, Russians used a pencil"
Another thing I tend to notice: sw companies that use CC WILL GO BANKRUPT
Not maybe, WILL.
Companies where software is not what the company essencially sells or only supports their operation can stand it (pretty much like a benign cancer)
Re:Meanwhile... (Score:4, Funny)
Re: (Score:2)
Have you put together a clear, serious, constructive proposal for an alternative that spells out the pros and cons? If you haven't, its your own fault really. But if you have, and they don't listen, then yeah, "shit" about sums things up. At any other time, I'd say find better bosses and quit in that situation, but few have that option at the moment.
Re: (Score:3, Interesting)
I feel you pain. I'm in the same boat. You can't work with CC effectively without 20-30 helper scripts. Hijacked/checked-out files is major pain. Dynamic views are great feature yet are completely useless.
Though that still doesn't mean you can't use Git like local tool.
I used before RCS (ci and co command) to preserve history of my modifications locally. Now due to various circumstances I moved to use Git locally and it works quite well.
After "ct update" (alias ct=cleartool), you go to directory
Re: (Score:3, Interesting)
Where do people get ideas like this? I use CC effectively with one trivial Perl script. It converts "my feature is on this branch off this label" descriptions into config specs -- raw config specs are too complicated to handle, so you need a layer above them which matches your CM process. Yes, IBM/Rational should explain that to their customers. Or maybe make UCM not suck.
Then you're not branching, lik
Re:Meanwhile... (Score:4, Interesting)
Where do people get ideas like this? I use CC effectively with one trivial Perl script. It converts "my feature is on this branch off this label" descriptions into config specs -- raw config specs are too complicated to handle, so you need a layer above them which matches your CM process. Yes, IBM/Rational should explain that to their customers. Or maybe make UCM not suck.
What about normal diff? CC still doesn't allow to use external diff program. And "ct diff" insists on two files - it can't diff hijacked file against original.
What about normal recursive diff for two branches?
What about patch generator? So that you can back up you unchecked-in changes.
What about change log? Recursive change log showing changes for all files in directory?
How about converting change history into set of patches? To allow easier investigation of regressions.
The moronism with R/O files? All extracted/"ct get -to" files are marked R/O.
And this is from top of my head. For all of that I have scripts. And with the scripts, I'd say, CC isn't half bad.
But to the point of original question, with Git I would not need any of the scripts.
Then you're not branching, like you're supposed to do, and a hijacked file is the *least* of your problems. You cannot use CC as if it was CVS; a dynamic view is not a sandbox if you set it up to silently show other people's possibly incomplete changes.
We do branching and hijacked files are not problem per se. It is just better half CC tools, when given as parameter hijacked file, would simply say "f-off, this is view private file."
In some situations checked-out files are even worse since CC treats checked out files like files on a special branch. Consequently half of CC tools accept the file as parameter, yet show dick but no information about the file.
Git doesn't draw any difference between the files and files in repo. At any time you can do whatever you like with any accessible file/revision.
Use them correctly for a few years, then report back.
Care to elaborate on "correct" usage pattern then?
People tried them in company few years ago and pretty much abandoned them. They are still accessible, yet generally unused. Our CC admins would be happy to know the "correct" usage for them.
You can't index dynamic view - because it contains all possible vobs and all possible files. And I do not want to deal with 150K files of the whole project, I need only 3.5K files belonging to my part.
You can't compile in dynamic view - because even if only dozen of people compile simultaneously, CC server simply dies under load.
Heck, simple "ls" spits on screen bunch of errors every time, because dynamic view can't properly show branch, but shows all files on all branches (readdir() lists all of them). And if file did happen to be not on the branch of the dynamic view, stat()ing it would give you an error.
If you can't do development with them, what else can you do with the dynamic views?
I used in past dynamic views solely for porting semi-automatically (with script) trivial fixes into many branches. For more than that dynamic views are useless.
Please, reveal me the secret: how do I use dynamic view "correctly"? Many people in my company would be happy to know it too.
Re: (Score:3, Informative)
Adopt a git... (Score:5, Funny)
Re:Adopt a git... (Score:5, Informative)
It's more than just an moron, it's an nasty, stubborn, selfsentered and selfish moron.
"Our neighbour is an right old git" could be used to describe an elderly neigbour who, say, regularly blocked your driveway because your car got in the way of the sunlight on his garden.
The old neighbour from Dennis, or Victor Meldrew from One Food In The Grave are both fine examples of gits.
It's like a weaker version of the c-word.
Re: (Score:2)
You mean... cvs?
Re: (Score:2)
Re:Adopt a git... (Score:5, Funny)
Yes, but only a cunt would say "the c-word".
Re: (Score:3, Funny)
In the language Dogg [wikipedia.org], the word 'git' means 'sir'. So one would politely ask a stranger: 'Cretinous pig-faced, git?', meaning 'Have you got the time please, sir?'
Then there's this [youtube.com].
Re:Adopt a git... (Score:5, Informative)
Re: (Score:2)
Not a moron really, at least in terms of UK usage. Stubborn and irritating, yes, but there is not really an implication of idiocy. The phrase "stupid git" is quite common and isn't a tautology. The OED rather bloodlessly defines "git" as "a worthless person".
Re: (Score:2)
In the UK and to a lesser extent here in Australia a "git" is akin to a moron.
Actually, git is more akin to "bastard" or "son of a bitch". You can say to someone "he was a clever old git" without it being considered an oxymoron.
Incidentally, Linus claims he named Git after himself.
Re: (Score:3, Informative)
I wonder if Linus knows?
Re: (Score:2)
Re: (Score:2)
We also have GIMP. I think there's some kind of competition going on ;)
Re: (Score:2)
Re: (Score:2)
My understanding always was, Linus wasn't too proud of having driven a wedge through the middle of the kernel community, that's what the "Git" was about. Now that he went on to change the entire world of revision control, I would say... the pain was worth it. Probably.
If it looks like a tree, you'll probably be fine (Score:5, Informative)
If the system you are migrating from manages trees, you should be fine. CVS migration is pretty easy and I understand that Perforce works quite well too (in both directions!). Most of the migration tools are listed in the GIT FAQ [git.or.cz].
The places where people are likely to have trouble is migrating from tools that don't understand that there's more than one file. For example, RCS and SCCS both support branches, but in a completely different way to git (branches are per-file, they're not for the whole repository). This means that during conversion, something useful has to happen with them, but the right answer isn't clear to a program. If versions 1.1, 1.1.1.1, 1.1.1.2 and 1.2 of file "foo" exist, then versions 1.1.1.2 and 1.2 are on different branches and either may be the older revision. It's not clear if revision 1.43.1.3 of file "bar" is the same "branch" as "foo" 1.1.1.2 or not. Because RCS and SCCS deal with single files only, it's not possible to find an answer to these questions in the history files at all - if there is an answer, it's just a convention of the user. Essentially what's happening here is that the git import process requires information which isn't represented in the files you're converting from. For what it's worth, migrating from SCCS or RCS to CVS has a similar problem.
Personally, I've migrated from CVS to git for findutils (well, Jim Meyering did the actual migration; he migrated coreutils too). I haven't regretted migrating at all. It took me a long time of using git locally before I was comfortable migrating the master repo, though. As a git beginner the thing I found most worrying was that I found it hard to envisage the effect of the git command I was typing. The thing it took me a long time to figure out is that with a distributed version control system, it's safe to screw up your local copy, as long as you don't push the result.
Re:If it looks like a tree, you'll probably be fin (Score:5, Interesting)
Right, that was always the weakness of git, and although it's improved I still have problems with its usability (or lack of it). For all the dumping Linus does on Subversion/Perforce and its ilk, they are easy to understand and it's basically always clear what you're doing. I haven't used git for a while, but last time I did it was like a box of sharp knives. Although hard to mess up the remote copy, messing up your local copy was much easier.
strategy (Score:4, Informative)
Comment removed (Score:4, Informative)
Re:strategy (Score:5, Insightful)
DVCS is in concept always better then centralized VCS, since it offers all the same features plus a lot more. However there are things that git handles pretty badly. Binary files are such a thing, you really wouldn't want to keep large binary files in git, since git forces you to download all the history of them, unlike SVN which allows you to only download the latest version. Another thing missing from git is a way to checkout just a single directory or file, when I am just interested in the latest version of a single kernel module its kind of annoying being forced to download the whole kernel source tree.
Re: (Score:2, Troll)
As just some schmuck who downloads sources over the internets for compilation, I will give my POV: git is shit! So far I have done pulls from cvs, cvsnt, svn, git, and mtn that I know of. Of these, the only one worth one tenth of one shit from the user's perspective is svn. Why is that? Because every other remote source code control system will happily corrupt your copy of the repository the majority of the time that there is some communications problem. In the case of svn, you can at least almost always re
I want to use git (Score:4, Funny)
Unfortunately I think I need a tool like TortoiseSVN for git because I am a git.
Re:I want to use git (Score:5, Informative)
Git + Eclipse (Score:5, Interesting)
I'm trying to use git as much as possible --- I'm still pretty crappy at doing anything even slightly complicated with it, but even with minimal skills it's brilliant at keeping track of changes to local directories.
The only problem is that I'd really, really like a decent Eclipse git plugin. I'm used to using Subclipse for SVN, which is fantastic: I can point at a file or directory, say 'Synchronise with repository', and then get a graphical diff of every change and the ability to quickly and easily revert or commit changes on a per-change, per-file, per-group-of-file basis, etc. (And you can do this with any revision, which makes backing out one specific change very easy.) Doing the same with git's command line tools seems terribly clunky by comparison, especially when I'm struggling to remember the syntax, and the fundamentally unfamiliar workflow.
I do use the Eclipse git plugin at git.or.cz, but it's still very crude. The file decoration is invaluable, which lets me see at a glance which files are new/changed/pristine in the Eclipse project view, but actually trying to *do* anything with it is deeply unpleasant --- no synchronise view, no graphical diff, and some weird behaviour like if you point at a file, say 'commit this', you get a dialogue prompting you to commit *all* files. Which is not what I want. And there's lots of UI clunkiness all round, due to simple immaturity.
I've had some luck with giggle, but the UI is pretty bad, and some changes (I forget what; new files, perhaps) don't show up in it, which is a bit awkward. I've had a play with some other GUI frontends but they're all pretty nasty by comparison with Subclipse. Still, the git plugin is getting better with time --- I'm just hoping that Synchronise shows up soon...
Re: (Score:2, Informative)
Comment removed (Score:3, Informative)
My (short) experience with git so far (Score:5, Interesting)
I used to use cvs, subversion and perforce. After switching to git, it feels a lot more powerful, at the cost of more things that can go wrong.
My workflow with subversion was:
- regular update: update, check/fix conflicts, continue work
- commit: update, pick files I want to commit with TortoiseSVN, verify the changes in the diff view, write log message, commit, continue work
On GIT:
- regular update: stash my changes, change to master branch, pull, check for errors or dirty files (mostly endian problems), switch to work branch, rebase from master, check for errors or dirty files, unstash my changes, check for errors or dirty files, continue work
- commit: update, stage the files I want to commit, commit them, verify the changes, push
At several stages some obscure thing could go wrong that I needed to look up in the manual or on the internet, or needed to ask someone who used it for longer. That doesn't mean I think GIT is bad, I just feel it takes more time to be fully productive with compared to older systems. And I miss a few minor things from svn, like keyword expansion or properties.
Until Git Tools are mature, SVN will do just fine (Score:5, Insightful)
I've just gotten fluent with SVN versioning after using it for a few years now. I understand that part of what bothers me about it is what bothers Linus Torwalds aswell and had him write Git and I can follow his reasoning in his famous Google speech on Git *and* I understand the hype that ensues around Git and welcome it. That said, until Git has a neat set of stable mature GUI tools to use with it, I'm sticking with Subversion, TortoiseSVN and/or Subclipse. A mature working toolkit that I know how to handle and that works more or less flawlessly.
Even a toolset like that would've costed thousands ten years ago. That goes to show how far we have come in some areas of the software field.
Mercurial vs. Git (Score:5, Interesting)
Re: (Score:3, Interesting)
Last I used Mercurial, I couldn't create a feature branch. I had to clone the whole damn repo. Well, either that or I could create a branch that lives forever, not a good idea if I'm doing a crazy experiment.
In Git, if I want to try something out, I create a feature branch (takes basically no time or disk space) and hack away. If it sucks, I just delete the branch. It's a very nice way to work once you get used to it.
Have they improved branching in hg?
Darcs (Score:2)
Comment removed (Score:3, Interesting)
Lack of Windows support is still a big issue (Score:3, Insightful)
Many of us develop on Windows, pushing out code to Linux platforms. Git just isn't an option. Poor support for IDEs, especially Eclipse.
Bazaar has been working great for me. Used Mercurial with success as well.
I tried "git cvsimport" and "cvs2git" (Score:3, Interesting)
Neither worked on my 18 yr old CVS repo (that was populated with 7 yr old RCS files). What I did find was fromcvs [dragonflybsd.org]. I found a couple of bugs, with the author fixed very quickly. It is also fast. My 3.5G CVS repo was converted in about an hour. Both of the others took 10+ hours (and didn't produce usable output). The biggest reason I love it: it allows incremental updates from CVS to GIT. You can run it any number of times and it imports the new stuff. You do need to leave the git repo you are importing into alone (no commits other than the import commits).
I still have more testing to do before we go live, but it's looking very, very nice.
TortoiseGit: the best shot at a Windows GUI (Score:3, Informative)
At work we're trying to get all our our repos moved to Git. We moved off of CVS to SVN a year or so (which was a huge improvement), but now that all of the non-programmers in the office are used to using TortoiseSVN [tigris.org], lack of a good windows GUI for Git has been a bit of a roadblock.
The msysgit [google.com] folks started work on Tortoise-inspired GitCheetah [google.com] GUI, but that project basically fizzled out. Lots of people wanted a Windows GUI, but no one had both the resources and drive to step up and do it.
Then, exactly two months ago, Frank Li started working on TortoiseGit [google.com]. From what I can tell, this is a fork of TortoiseSVN with most of the Subversion guts pulled out and replaced with git commands. TortoiseGit is not done yet: 'git add' has some issues, Submodules don't seem to work at all, etc..., but development on the tool is in high gear and the primary developer is going the extra mile to help users [google.com].
If you're looking to deploy tools right now, gitk is a bit more powerful than the log in TortoiseGit, but might be more confusing for naive users.
How does it work with non-static IPs? (Score:4, Interesting)
Re: (Score:3, Informative)
There aren't any strict rules saying that people have to pull straight from your laptop.
In terms of non-distributed VCSes, would you ever host a your repository on a machine that other people couldn't access? It would always be somewhere publicly accessible.
For this kind of situation, you'd probably have a public development repo that's separate from your official repository. This would give you a set of repositories that looks like:
official - The authoritative repository, controlled by some kind of integra
Re: (Score:3, Informative)
Take a page out of Freedesktop.org's process. Any user can create and maintain user repositories in their own space. For example, http://cgit.freedesktop.org/~csimpson/mesa [freedesktop.org] is my personal Mesa repo. Then, anybody that wants can pull from there. Very rarely do FD.O people pull and push directly to each other, and I doubt that it happens that way in larger organizations, either.
@#$@#$ git! (Score:5, Informative)
I curse more when I use git than when I use Windoz (and those are the only times I curse). Git's design is really that bad (from a user perspective).
Git is fully distributed (with no "authoritative" source), but it doesn't give you any tools understand/manage the distribution of files. If you have a work group with more than a few people, you are constantly asking what repo (and what access method to it), what branch, and what (bombastically long) revision. It's fine for 1-2 people, but then any version control system is fine for a small enough group.
The documentation helps little. When you do "git help merge", you don't @#$@# care that this is the front end to multiple merge methods. You just want the stupid thing to work. If it's a special case, then you'll look for an advanced technique; but you are stuck reading through all this crap trying to figure out what really matters. No offense to the people working on git docs. It used to be awful, now it just sucks. The problem is more in the user interface design than the docs.
There are over 100 git commands, and a command can do radically different things depending the the switches and target syntax. It's more confusing than any other revision control system that I have worked with.
I use git because I have to, not because I want to (like Windoz). After using it for months, I still routinely get stuck trying to figure out the right mix of commands, arguments, and target syntax needed to get common things done.
Git can do some (nice) things that subversion can't, but it creates so many problems that you haven't gained anything.
I've heard good things about mecurial and bazaar. I wouldn't recommend git to anyone I liked (but it's perfect for perl :-).
complexity (Score:3, Informative)
The complexity of git robs it of quite a bit of the value of it's features. For God only knows what reason, a 5-6 person project that i'm working on is using git instead of subversion, and only the person who setup the project actually has any idea how to use git. The rest of us are just cruising along, not really having any idea of what we are doing with it, and are stopped completely whenever it does anything weird.
It's awesome to have the whole thing where it merges all the changes in a same file together, fairly intelligently, but even the GUI version for Windows has no functional interface for how to deal with conflicts (which should be easily done as a "which bit of code is the proper piece to use here?" instead of jamming diffs into a file. Also, the Windows and Linux versions of GIT have several problems interoperating with each other.
In short, Git appears to have been designed entirely with features in mind, and not one bit of usability for anyone other than Linus himself. It is a nightmare for people who only have the need for version control and a handful of people working together. It reminds me very, very much of early Linux, before anyone else besides Linus had been hacking on it.
Re: (Score:3, Interesting)
Lots to talk about here!
The complexity of git robs it of quite a bit of the value of it's features. For God only knows what reason, a 5-6 person project that i'm working on is using git instead of subversion, and only the person who setup the project actually has any idea how to use git.
It sounds like the first person set up the project, and now expects everyone else to just "make it work", even if they're not programmers and have a good understanding of Git. Fair 'nuff.
Now I don't know your situation, but if you're actually in a work situation, the lead programmer (or user, if you're not storing code in this repository) should be giving you guys some kind of help or crash course in using Git. The Git model is quite a bit different than SVN, and it has taken me some
"Better"? (Score:2)
In what way?
I'll happily admit that I do prefer bzr for its UI, but I hardly think either is objectively "better", whatever that means.
Re:bzr vs. git? (Score:5, Informative)
I always though bzr had the edge on git in terms of being a better DVCS. Is there a reason why the article seems to think that git is the default?
No such thing as 'better' here.
Bazaar was the runner-up DVCS, and rightfully so, but it has both advantages and disadvantages. Git is faster and currently more popular. Bazaar has an easier interface, better GUIs, is more easily extensible (Python), and runs better on non-Linux platforms.
So which you prefer is a matter of what you are looking for.
Re: (Score:3, Informative)
Re: (Score:2, Insightful)
Re: (Score:3, Insightful)
Free software tends to soar.
Re: (Score:2, Insightful)
Git is Free and does not cost thousands of dollars. Two pretty good reasons.
Re:Why is it soaring? (Score:5, Informative)
It's four good reasons.
1. You can use git for any purpose. You have to pay serious coin before you can use Bitkeeper for any purpose.
2. You have the freedom to see how git works, down to every last line of code. I can't comment on whether Bitkeeper also includes this level of freedom.
3. You can make any damn changes you want to Git, without prior approval.
4. You can pass on all these freedoms, and the freedom to use your change, to anybody you want. It was precisely the fact you can't do that with Bitkeeper that led to it being dropped by the Linux developers and replaced with a coded-from-scratch replacement.
Re:Why is it soaring? (Score:4, Informative)
Re:Why is it soaring? (Score:5, Informative)
It's worse than that. The bitkeeper author at one point tried to extend that as a ban on anyone who works for a company that has a competing product with bitkeeper.
Re: (Score:2)
Comment removed (Score:5, Interesting)
Re:Why is it soaring? (Score:4, Insightful)
Try pushing a change into another Git repository, then navigate to that repository and run "git status" - git does not auto-checkout changes in the destination repository during a push. It's the user's responsibility to detect this and deal with it. I find that design approach - the idea that the user is expected to spot and deal with the internal behaviour of the tool - to be pretty bad.
At first, I found this pretty unintuitive, however, I now feel that automatically checking out the changes would be a Bad Thing(tm).
Most of the time, repositories you push to will be bare repositories, with no working tree. If there is a working tree present, then presumably someone is actively working on it. Imagine you are implementing some new feature in your local copy, which is all very experimental, and perhaps not even compiling yet. Now imagine someone pushes a major refactorisation directly onto your working tree, which does not merge cleanly. I would find this exceedingly annoying. [You have not yet committed any changes, and so the push does merge cleanly with the HEAD, but just not the working tree]
In addition, I think it would be quite distracting if bits of code changed behind my back, when I wasn't expecting it. Especially if I happened to be editing the file in question when it got updated.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Why is it soaring? (Score:4, Informative)
Re: (Score:2, Interesting)
Re: (Score:2)
I haven't used Subversion.
I have used Perforce & CVS.
Perforce beats the pants off CVS - no competition at all.
Re: (Score:2, Interesting)
Does bzr provide any attempt to sanitize incremental revision numbers? I know that both Mercurial and SVK have issues where you need to figure out that "my r9342 is your r8929". Git avoids this issue entirely since my repository's 92a560f20e72e4296c782d3fbb4706e6946d6209 is always going to be your 92a560f20e72e4296c782d3fbb4706e6946d6209, assuming you have the same commit of course ;)
Re: (Score:3, Informative)
huh ? mercurial has no issue with revisions numbers, revisions are indexed with a hash just like git . The sequencial numbering is available as a convenient alternative for referring to a rev, that's all.
Re: (Score:2, Informative)
hg has both a revision number and a changeset id. The revision number is human readable and useful within a particular repo. The changeset id is unique across repos, the same as git does.
Re: (Score:3, Informative)
The main advantage of git over subversion for such uses is that git doesn't require a seperate repository, the repository sits right there in the .git/ directory in your projects directory. Doesn't sound like much, but its great convenience factor, since all you have to do to start using git is type 'git init' and you are done, you don't need to create a repository, you don't need to important your existing files and most importantly you can leave your working directory as is. With SVN this same process can