Git 2.0

[ultimoo]

I find git's growth and adoption remarkable. It was only 5 years ago that as a young programmer I was first exposed to git and the concept of version control. I remember that every other team I knew at my organization was using svn and no one really understood how git could improve their workflow or how it worked and what it brought to the table.

Now that I look around, almost everyone in the programming world (at least the part I'm exposed to) is familiar with git as a version control software and github as a social-coding/code-hosting site.

[jasonkester]

I've been using git (and GitHub) at my day job for a couple years now, and I'm still not sure I'm sold on it over Subversion.

In the past, version control was something that existed but you never had to think about. When you got to a good place, you'd hit the big red Save Button and up your code would go. Once in a blue moon you'd step on somebody's changes and have to do a quick merge. No big deal.

Now with Git, version control is part of the workflow. It's never far from your mind. You're creating branches before writing code (versus creating branches three times a year when you needed them). You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes back into the IDE just so that the source control system (and possibly some ops overlord somewhere) doesn't get mad at you.

I'm sure there are times where Git has actually made things easier, but most of the time it's just one extra thing taking up my attention.

It's like timesheets for your code. Not a big deal, but ever so slightly insulting that you have to deal with them.

[ams6110]

Just be glad you never had to use Visual Source Safe. Makes svn look like a dreamland.

[jammycakes]

You can get some interesting usage statistics from job tracking websites such as itjobswatch.co.uk. In the source control market, Git is now the most widely used (3461 jobs) with Subversion second (3181) and TFS third (2035). Mercurial is a distant fourth with 268 and just about everything else seems to have fallen off a cliff in the past couple of years or so.

The other thing that Git has achieved is that it is now the de facto standard for source control in a way that no other source control tool has ever been. An increasing number of ecosystems don't support anything else and most best practice guidelines that you find on the web assume that you're using it, or else tell you to switch if you aren't.

I suspect that it won't be long before not using Git will start to count against you in the jobs marketplace, whether you're a candidate or a recruiter.

[joeblau]

Yeah, I just picked up git about 3 years ago and I probably wouldn't even take a job if they were using one of the other DVCSs.

[jaseemabid]

Its a surprisingly awesome s/w for a '2.0'

[benihana]

Well said. The funny thing is, switching from svn to git was what it felt like to switch from from other SCMs to svn.

I think git is going to prove to be one of those pieces of software that is just transcendent.

[justinmk]

> "git rebase" learned to interpret a lone "-" as "@{-1}", the branch that we were previously on.

Cool, I was just looking for something like this with "git merge". Turns out "git merge" already supports it, and I need to get better at using the reflog (@{...}).

> "git add <path>" is the same as "git add -A <path>" now.

> The "-q" option to "git diff-files", which does NOT mean "quiet", has been removed

More intuitive.

> The bitmap-index feature from JGit has been ported, which should significantly improve performance when serving objects from a repository that uses it.

Improves clone performance if you're pulling lots of history, but there still doesn't seem to be a way to sparse-checkout without fetching the entire .git repo.

[wfn]

> but there still doesn't seem to be a way to sparse-checkout without fetching the entire .git repo.

I'm not entirely sure if this is what you want, but sparse-checkouting only parts of the repo is possible: http://jasonkarns.com/blog/subdirectory-checkouts-with-git-s...

For cloning a particular branch, there's also (since 1.7.10)

  git clone -b your_branch_name --single-branch git://some.remote/repo.git

[jackyb]

Use "git clone --depth [depth] [remote-url]"?

[dj-wonk]

I can't tell if Git, the project itself, uses semantic versioning. Is 2.0 considered a major (backwards-compatibility-breaking) release?

[goldfeld]

Off the top of my head, I'd say it has breaking changes such as changing push.default's default setting to only your current branch, as opposed to pushing all branches when you do a 'git push'. Git cli has been warning me of this change for a while where I didn't have a configured push.default, so I'll assume this is as 'breaking' as it gets.

[erikb]

Yes, that's exactly what it's saying. I'm really, really happy that these versioning schemes become more popular and that people really start to read something into it. In my company people's opinion about Git2.0 is strongly split. Some people understand an increase of the major to have API changes, while the others didn't know about this versioning scheme and got a lot of unexpected problems.

[ww520]

Is there a summary for the new features in 2.0?

One feature I really hope git to add is an easy way to clean up deleted files in the repository. Some times I accidentally check in some large zip files or built files and that really blows up the repository size. Those files stay in there even if I've deleted them. It's a pain to clean them up.

[beaumartinez]

There is, in the linked article.

[joemaller1]

So I'm excited this is finally here. But I'm also terrified. You go first.

[kzrdude]

The changes feel extremely conservative. That's ok, but it's not exactly "exciting" nor is it scary.

[zobzu]

I wanted the auto gpg sign for a while. I wonder if itll get more adoption.

[jc123]

Git is remarkably deep in its functionality that its possible to learn something new about it on a weekly or even daily basis: if you have the time. Whenever you are trying to manipulate code, there is usually a clean way of doing it in git if one takes the time to master its power. Next time you have such a problem, if you have the time, take the opportunity and you'll probably pleased at learning something new instead of using what you currently know about git plus a workaround or two.

[yeukhon]

For me the amazing thing about writing VCS is that a subtle bug or change could destroy someone's history and future commits. For example, in some old Mercurial release, hg mv had a bug (something affects history integrity) and the bug is fixed in recent release (the default version install on Ubuntu 12.04 should see that bug).

Maybe I lack of the domain knowledge, but writing VCS must be a very difficult task if you care about preserving history.

[ams6110]

Nothing unique about VCS. A subtle bug in a word processor has the potential to destroy someone's manuscript. A subtle bug in a payment processing system has the potential to expose a million credit card numbers. This is the nature of software.

[sjwright]

No, it won't, because you keep your workstation backed up. You do keep a backup, right?

[spb]

How common is this style of describing changes to parts of code as "teach" and "learn"? I like it.

[_RPM]

I'm about to graduate with CS degree, and my first question to potential employers is going to be "Do you use source control, and is it Git?"

[burkaman]

I would try not to judge companies like that. I had an internship at a place that was consistently rated the best place to work in the area, interesting work, great development environment, etc., but they used this source control product called AccuRev. It was this slow GUI-based thing with it's own unique vocabulary, nobody really liked it, but it was still a great place to work.

If they don't use source control at all, that's obviously a problem, but don't discount a company just because they don't use your favorite software.

[hueving]

And what is your follow-up when they say they don't because they need more centralized control/auditing due to the sensitivity of their work?

[maaaats]

And during that degree, you learned the pro's and con's of every VCS and when to use which, I guess? I'm soon graduating myself, and I would never dream of believing that I know better than those with more experience than me.