Confessions of a Git Skeptic

git has cut the team in 2. The graphic designers no longer know how to commit their work, nor do the frontenders, nor do most of the project managers. In particular, when a conflict comes up, nobody knows how to resolve the conflict (with Subversion we had a simple rule: "If you get a conflict, save your work outside of the project, then "accept theirs full", then re-integrate your work. A pain, but non-technical people could manage it). Instead, all of those people now send their work to the programmers, via email or Dropbox, and they say "Please integrate this into the project". This increases the amount of work that the programmers have to do.

We now use git for everything, because it seems like it is the thing to do, and it helps the programmers merge their work together. But the price is high: the loss of half the team, who can no longer use the version control system.

The eureka comes when you stop using git by retrofitting Subversion workflow on it. The "Git forces me to learn obscure things" part precisely shows that.

The hardest part is not learning "obscure" git things, it's unlearning the habits and preconceived ideas about how SCMs work.

- git rebase -i (the "cleaning" of history)

- git add -p (which requires a separate staging area)

- Using a bare repository (which, just for the record, I've also had to do with SVN, but we didn't have a special Googlable term for it)

- Track the difference between a local and remote branch (this is actually inherent to DVCS workflow, it's like going from DOS to UNIX and complaining that they make you track file permissions... you didn't even have the option on DOS!)

It's actually kind of embarrassing to see an SVN user claim that they don't understand the difference between a downstream concept of a central repository and the remote concept of the same repository, because I can sure as hell remember having to run "svn up" before "svn ci" just in case someone had made a commit to the remote repo in between the time of my last update and my upcoming commit.

master, "origin/master", and origin's own master all have corresponding concepts in SVN, even if master and origin/master had to be the same by definition.

One more thing: I'm pretty sure SVN now has only one .svn directory, just like git.

Having a local repo and push/pull to any other repo is not a complication but a huge advantage. It lets you do things like commit while you are on an airplane, or share committed work in an internal team before pushing to trunk, or keep repo history even if the server dies in a fire. It lets you not have to worry about who can be trusted with commit permissions or not. Being able to commit all the time without pushing lets you keep revision history without checking in, so you don't end up with many copies of your working directories, or saving up changes before you are 'allowed' to commit.

Since you can commit all the time, you can destroy the working tree trying things out and then bring it back if they didn't work.

So let's not complain about having a working tree, local repo, or remote repo. The staging area makes it so that you don't have to complete all staging of many different files in one huge command. You can add/rm something, preview what's staged, and only commit when you are satisfied.

In addition, CVS type merge is a pain while it is actually much simpler with git or hg. And being able to keep rebasing your private feature branch on a changing remote branch is a huge improvement.

The "extra steps" (the index, remote branches, etc.) are there for a reason, and that reason is to give you the tools to be careful with your codebase.

I always use `git fetch`, for example, because unless I've been doing something reeeeally weird, `git fetch` will never touch my local work. At all.

The index allows me to make sure I know exactly what I'm committing, and the extra step gives me the chance to look over it once again before I commit. (`git add -p` and `git commit -v` help a ton here, even though it feels like they "slow things down"). I never have "Oops, I didn't mean to commit that" moments anymore.

And the merging model (yes, with those opaque commit-hashes and mutable history and 3 kinds of branches) allows me to fix things when I screw up (or one of my coworkers does). Which still happens all the time, because we're human.

I think you could get a lot more out of git if you were willing to invest the time to learn more about its branching model (which really is elegant once you understand it), and to configure it properly. Otherwise, you may have a look at Mercurial, which has a more svn-like experience.

Git's command line is a UX train-wreck though. Poor consistency, learnability and leakage about how the internals work. I think Git gets a lot of unnecessary flak because even though people realize it's superior, they are always fighting it into doing what they want.

My pet project is giving it a saner command line.

> Git allows the topic-branch development style, where you maintain one short-lived branch for every task you work on. Like many people, I learned about this style from distributed version control. I love it. It’s an excellent way to switch between tasks, and maps well to the way I actually think about the state of the project. But you don’t need Git to do this! Subversion has “svn switch”. It does have an annoying problem that if you specify the wrong URL to switch to, it will trash your local copy rather badly. However, Subversion seems to have fixed that problem in version 1.7.

Quite an annoying problem. I'm not really sure why the author is a git skeptic if it enables and introduced him or her to a wonderful workflow.

The ability to easily work on multiple branches and make offline commits is a huge selling point for any DVCS. I really like git rebase and git add -p now as direct arguments for git, but wouldn't have used them right away.

Edit: added clarification after quote

But underneath, the concepts are pretty simple, and because it's the right simple concepts, the things you can do with it are pretty flexible, and thus powerful.

Git's interface can defn be way better for the default case. But everyone and every team's workflow is different, so the inherent flexibility will always involve a little bit more complexity.

And oh, it seems that he hasn't yet discovered selective commits or stashing, so staging seems like an extraneous extra step.

And rewriting history seems frivolous if you work by yourself. But it makes pull-requests on open source projects way easier to manage if your commits are clean. And if you need to rollback to a working version of your production code, it helps to have clear commits too.

His explanation was on the lines that if there are 100 developers working on different trees of freebsd and they want to commit their work, it causes a race, as if some one commits before you, you need to do a git pull, incorporate changes and then push, even when they are working on unrelated components.

My response to this was yes, and that is why git allows you to create branches so cheaply, but he still was not convinced.

My thoughts in this entire learning process was along the lines of - "Why the hell are they doing it like this, instead of that? Why are they calling this, like that, instead of just calling it what it already is?"

In my experience trying to learn GIT, I was able to conclude that GIT introduces a LOT of terminologies, and concepts, making the path for beginners like me more and more difficult. Whether spending hours learning these concepts just to get your stuff synced properly depends on your scenario. But for me, SVN rules.

Also, there is another REALLY brilliant way by which SVN helps me. I use Tortoise SVN. I have a couple of external 1tb hard-drives to back-up my code. I like to take regular backups (obviously) because some of the code is in production and I just want to play it safe. Using SVN, on windows, I run an SVN server on my machine, and create respective repo's on my hard-drives and just update them and voila - I have all the code properly backed-up and versioned. You can also automate this (there are scripts to do them), but for me, I like to keep it synced manually. And also, you can keep your stuff backed-up to your Google drive by making a repository inside your drive folder. I can't imagine typing all these as commands in GIT.

_The_ git repository is right there on your computer.

Subversion got rid of those directories in version 1.7 (http://blogs.wandisco.com/2011/10/11/top-new-features-in-sub...)

Also, for the searching problem: betterthangrep.com. The reason I have perl installed on the Windows box at work.

I appreciate Git and hate going back to SVN when clients demand, but I'm convinced it takes a certain kind of brain to feel comfortable with it.

"You can use “pull” to mean “fetch and merge”, but some authorities will advise you not to. You can also use “commit -a” to avoid the “add”, but you still have to be aware of it."

Whatever tutorial I originally used to learn Git made use of `git pull` and `git commit -a` exclusively, without any elaboration. It wasn't until long into my Git career that I was even aware of `git fetch` or `git add`. To this day I use `git add` only occasionally (but it's so useful when I do need to use it), and I honestly can't think of a case where I've needed `git fetch`.

I'm about to teach my co-workers to use Git for a project I'm spearheading, and I intend to expose them to this simplified view and let them fill in the blanks when needed.

If you do an add, followed by a "git diff --cached", you can view what's going to be committed before you do the actual commit.

I've found this workflow to be useful, since it helps see things like debugging print statements that crept in, or unnecessary files accidentally added ("git diff --cached --stat" is useful for the latter).

This is the biggest issue I've always had with Git. I've struggled to understand why so many developers swear by a system that takes several steps backwards from other systems.

while git has submodules, they no way near have the flexibility of externals. if git would incorporate the idea of externals, I think it would cure quite a few people's complaints.