views:

6364

answers:

10

So I'm in the process of getting GIT sold at work. First thing I need is to convince everyone that GIT is better at what they're already used to doing. We currently use Perforce. Anybody else go through a similar sale? Any good links/advice?

One of the big wins is that we can work with it disconnected from the network. Another win IMO is the way adds/checkouts are handled. More points are welcome! Also we have about 10-20 devs total.

+4  A: 

The command that sold me on git personally was bisect. I don't think that this feature is available in any other version control system as of now.

That being said, if people are used to a GUI client for source control they are not going to be impressed with git. Right now the only full-featured client is command-line.

Ryan
For fairness (I picked git over Hg) it has to be noted that Mercurial has bisecting capability too – although it ships as a plugin that you have to load explicitly.
Aristotle Pagaltzis
darcs has had "trackdown" since before git existed. The early versions were pretty rough, admittedly.
wnoise
regarding UI - GitX on OSX is excellent.
Antony Stubbs
+1  A: 

I have no experience with Git, but I have with Mercurial which is also a distributed VCS. It depends on the project really, but in our case a distributed VCS suited the project as basically eliminated frequent broken builds.

I think it depends on the project really, as some are better suited towards a client-server VCS, and others towads a distributed one.

Terminus
+19  A: 

It would take me a lot of convincing to switch from perforce. In the two companies I used it it was more than adequate. Those were both companies with disparate offices, but the offices were set up with plenty of infrastructure so there was no need to have the disjoint/disconnected features.

How many developers are you talking about changing over?

The real question is - what is it about perforce that is not meeting your organization's needs that git can provide? And similarly, what weaknesses does git have compared to perforce? If you can't answer that yourself then asking here won't help. You need to find a business case for your company. (e.g. Perhaps it is with lower overall cost of ownership (that includes loss of productivity for the interim learning stage, higher admin costs (at least initially), etc.)

I think you are in for a tough sell - perforce is a pretty good one to try to replace. It is a no brainer if you are trying to boot out pvcs or ssafe.

Tim
I'll add that Git's remarkable feature set comes at the cost of a steep learning curve. (Though I never found Perforce all that intuitive either.)
savetheclocktower
I updated the question. I can assure you I'm not trying to sell this to get to use the latest and greatest VCS. My boss is sold, we just need to sell the rest of the team.
Justin Bozonier
Great answer Tim.Justin - why is your boss sold? Surely you must have addressed Tim's question to do that? I would be interested in the justification too.
Greg Whitfield
The biggest reason he's sold is the ability to use Git in a disconnected state. On top of that we only use the basic features of p4 and Git is much easier to use for our general use case. We're taking a look at how others use p4 and making sure we can do it with Git.
Justin Bozonier
You do have to pay for Perforce in a commercial environemnt, and really I have always find that Perforce jarring to use. And the only strength I really see is that it's good at handling huge binary blobs.
Calyth
+7  A: 
Thomas L Holaday
Not sure about what "multiple workspaces on single machine" means -- other VCSs simply don't have the concept of a workspace so it really cannot be touted as a feature for Perforce. The others make sense though.
Billy ONeal
Thomas L Holaday
+16  A: 

The Perl 5 interpreter source code is currently going through the throes of converting from Perforce to git. Maybe Sam Vilain’s git-p4raw importer is of interest.

In any case, one of the major wins you’re going to have over every centralised VCS and most distributed ones also is raw, blistering speed. You can’t imagine how liberating it is to have the entire project history at hand, mere fractions of fractions of a second away, until you have experienced it. Even generating a commit log of the whole project history that includes a full diff for each commit can be measured in fractions of a second. Git is so fast your hat will fly off. VCSs that have to roundtrip over the network simply have no chance of competing, not even over a Gigabit Ethernet link.

Also, git makes it very easy to be carefully selective when making commits, thereby allowing changes in your working copy (or even within a single file) to be spread out over multiple commits – and across different branches if you need that. This allows you to make fewer mental notes while working – you don’t need to plan out your work so carefully, deciding up front what set of changes you’ll commit and making sure to postpone anything else. You can just make any changes you want as they occur to you, and still untangle them – nearly always quite easily – when it’s time to commit. The stash can be a very big help here.

I have found that together, these facts cause me to naturally make many more and much more focused commits than before I used git. This in turn not only makes your history generally more useful, but is particularly beneficial for value-add tools such as git bisect.

I’m sure there are more things I can’t think of right now. One problem with the proposition of selling your team on git is that many benefits are interrelated and play off each other, as I hinted at above, such that it is hard to simply look at a list of features and benefits of git and infer how they are going to change your workflow, and which changes are going to be bonafide improvements. You need to take this into account, and you also need to explicitly point it out.

Aristotle Pagaltzis
+5  A: 

I think in terms of keeping people happy during/ post switch over, one of things to get across early is just how private a local branch can be in Git, and how much freedom that gives them to make mistakes. Get them all to clone themselves a few private branches from the current code and then go wild in there, experimenting. Rename some files, check stuff in, merge things from another branch, rewind history, rebase one set of changes on top of another, and so on. Show how even their worst accidents locally have no consequences for their colleagues. What you want is a situation where developers feel safe, so they can learn faster (since Git has a steep learning curve that's important) and then eventually so that they're more effective as developers.

When you're trying to learn a centralised tool, obviously you will be worried about making some goof that causes problems for other users of the repository. The fear of embarrassment alone is enough to discourage people from experimenting. Even having a special "training" repository doesn't help, because inevitably developers will encounter a situation in the production system that they never saw during training, and so they're back to worrying.

But Git's distributed nature does away with this. You can try any experiment in a local branch, and if it goes horribly wrong, just throw the branch away and nobody needs to know. Since you can create a local branch of anything, you can replicate a problem you're seeing with the real live repository, yet have no danger of "breaking the build" or otherwise making a fool of yourself. You can check absolutely everything in, as soon as you've done it, no trying to batch work up into neat little packages. So not just the two major code changes you spent four hours on today, but also that build fix that you remembered half way through, and the spelling mistake in the documentation you spotted while explaining something to a colleague, and so on. And if the major changes are abandoned because the project is changing direction, you can cherry pick the build fix and the spelling mistake out of your branch and keep those with no hassle.

tialaramex
There's no reason you cannot have a private branch of a centralized system either. DVCSs sometimes do better at merging, but just because the private branch doesn't exist on the remote repo doesn't mean that you can't create a branch only for you which exists on the remote repo.
Billy ONeal
This comment is technically correct, but that's sort of missing the point. Revision control systems are a social tool. Socially the branch with your name on it in the shared server isn't "private" it's shared. Yes, even with ACLs and whatever in place. There are technical differences too (obviously my git private branch is used while I'm commuting home, with no/unreliable Internet) but they're subsidiary to the social difference.
tialaramex
+1  A: 

Apparently GitHub now offer git training courses to companies. Quoth their blog post about it:

I’ve been down to the Google campus a number of times in the last few weeks helping to train the Androids there in Git. I was asked by Shawn Pearce (you may know him from his Git and EGit/JGit glory – he is the hero that takes over maintanance when Junio is out of town) to come in to help him train the Google engineers working on Andriod in transitioning from Perforce to Git, so Android could be shared with the masses. I can tell you I was more than happy to do it.

[…]

Logical Awesome is now officially offering this type of custom training service to all companies, where we can help your organization with training and planning if you are thinking about switching to Git as well.

Emphasis mine.

Aristotle Pagaltzis
+2  A: 

I use Perforce at work. I also use Git because I would still like some form of version control when I'm working on code and can't connect to the server. No, reconcile offline work just is not the same. Here is where I've found git to be a great benefit:

  1. Branching speed - git takes a few seconds at most.
  2. Conflicts - P4Merge's auto resolve destroyed a week's worth of work once. Ever since then I would rather resolve by hand when merging. When Git prompts me about a conflict, it is actually a conflict. The rest of the time, git resolves stuff correctly and I save heaps of time.
  3. Keeping track of merges - If you have one branch that is continuously receiving merges from two other branches, you know what a headache this can be with perforce. With git, the headache is minimized because the result of a merge in git is actually a new commit which knows who its ancestors are.
  4. Permissions - I have lost track of the number of times I've tried to work on a file but couldn't because it was not checked out in Perforce. If you worked with XCode (or any editor that does not have a solid Perforce SCM plugin) offline, you know how irritating this can get. I don't have to worry about that with Git. I make my changes. Git does not stop me and tracks them in the background.
  5. Keeping the main tree tidy - With git, I can sort my commits and tidy the code up so that the history looks nice and tidy. None of that "checking in this file because it was supposed to be part of the previous checkin" rubbish. I squash commits like that, because they help nobody.
  6. Stashing - Your perforce server needs to be version 2010.1 or newer to use the p4 shelve command.
  7. Creating patches - Easy to do in git. Don't know if it is possible in Perforce without using the command line.
  8. Mailing patches from the GUI - again, git wins here.

Well, that's my 2 cents. In Perforce's defense, I gotta say their customer support rules and so does their Time Lapse View tool. I do not know how to get a time lapse view with git. But for the convenience and time saved, I'd go with git any day.

carleeto
re #6 (stash): p4 shelve, it's new.
Trey
Thanks. I've updated my answer :)
carleeto
A: 

Lack of a good Mac OS X GUI client for GIT is a major down vote for it for me. (Use Cornerstone for svn, used Perforce GUI client).

Dad
I found GitX to be adequate. What's it missing?
dash-tom-bang
"adequate" pretty much sums it up, don't you think? I consider "adequate" below "good" and a far cry from "excellent" :-) The real answer is probably that I tried running GitX and it was ugly (compared to Cornerstone or Versions), probably lacked comprehensible online help, and I couldn't even figure out which of the too many versions was the Current Real Good Version (the gitx site wasn't it for some incomprehensible reason). This seems to be normal in git/dvcs world, but makes no sense to me. I just want the best well tested version when it comes to dev tools. not with OSS dvcs; very messy
Dad
+1  A: 

Lack of ability to fetch a single file/directory out of the repo is a major down vote for me for git/hg/bzr/etc.

nairbv