The Rise of Git

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."

Comments

It's because

[cameroneagans]

git is better than all the other VCSes

Re:It's because

[Anonymous Coward]

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

[shadowrat]

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

Re:It's because

[Anonymous Coward]

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

[bmo]

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

--
BMO

Re:It's because

[Mad Merlin]

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

[Anonymous Coward]

Microsoft?

Re:It's because

[girlintraining]

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

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

Re:It's because

[bgat]

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

[Anonymous Coward]

More correctly phrased:

"Git sucks less than all the other VCSes"

Re:It's because

[Anonymous Coward]

> 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

[siride]

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

[ls671]

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

Re:It's because

[wagnerrp]

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

[wagnerrp]

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

[Anonymous Coward]

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

Re:It's because

[MemoryDragon]

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

[jimmydevice]

Snort! And most of it's dead code.

Re:It's because

[jimmydevice]

Crap! I meant UN-EXECUTED code.

Re:It's because

[m.dillon]

Well, you should post with your real name if you are going to make such an encompassing statement, instead of anonymously. I'm kinda wondering what repo management tools you are using that can handle 50GB+ data sets that you are trying to compare against something like git?

From my experience handling large data sets is less a function of the repo and more a function of disk bandwidth and memory. Putting, say, a million files into a repo (any repo) is not a big deal but managing it will definitely be dependent on the operations you are trying to do, memory, and storage.

I've found, in general, for the DragonFly project which manages ~500MB and ~1GB repos, that regardless of the repo if you want operations to be efficient you need to have a high speed caching layer helping out the filesystem. For DragonFly, of course, that means having a SSD in the system and using the swapcache feature to cache filesystem data and meta-data on the SSD. Then repo operations run fast regardless of the repo system used.

A nominally priced SSD can cache 100G of data fairly cheaply, so handling a large repo isn't a big issue. In our case we have two machines which keep about a dozen repos from different projects synchronized, in order to make them available to our developers, as well as perform incremental translations from CVS to GIT for pkgsrc (which is an ultra-nasty script). The scripts run twice a day and have a run-time of around an hour with the SSD caching layer. Without the SSD caching layer those scripts will take 6+ hours of time to run (12 hours a day of run time if I run them twice a day). The SSD makes a huge difference in manageability.

In terms of trying to manage fewer larger files, such as images... large numbers of binary files are best managed outside the repo infrastructure. Sure, a few here and there (such as a web site's icons) can easily be managed inside a repo, but trying to manage large amounts of bulk data in a repo generally just results in a lot of unnecessary pain. It's better to manage bulk data in a filesystem capable of performing snapshots.

Similarly for backups... repos aren't good mechanisms for making backups. You want something more closely integrated with the filesystem (and the filesystem's snapshot capabilities presuming you are using a filesystem with snapshot capabilities) to do LAN and off-site backups. Not a repo.

So the question here is: Are you complaining about the amount of time it takes to do an operation due to being disk-bound, or are you talking about bugs in the repo system causing the program(s) to crash or eat too much memory? I haven't had any significant memory issues with git myself though I can definitely see needing a 64-bit VM space if the repo becomes large enough for certain operations.

-Matt

Re:It's because

[m.dillon]

Yes, but at the same time I only recall a few minor instances where I ever wanted to extract just a portion of a CVS archive, and the only reason was because, at the time, the system I was running on wasn't all that fast.

These days extracting a repo, even a large one, doesn't take all that much time, nor is disk space that big an issue. I just extract the whole thing (git, cvs, whatever) and then pick out what I want.

It only takes ~3 seconds or so to switch branches on a checked out repo of around ~100,000 files, and certainly less than ~10 seconds to do an initial checkout of such a repo. Not to mention the fact that 2TB hard drives are $100 these days so there's no real excuse to be tight on disk space.

When I first started using git I did worry somewhat about disk space. I quickly came to the conclusion that a few extra gigabytes didn't matter in today's world of cheap multi-terrabyte hard drives. I typically have 4-5 copies of the DragonFly source base broken out, each with its own copy of the .git repo. A simple git pull is all I need to synchronize whatever directory I've decided to work in (since I'm often reviewing other developer's branches I have multiple independent copies). That's how little I care these days.

That said, it *is* possible to tell git to hard links or otherwise share repo files in order to reduce the size of the .git/ subdirectory in the checkout directories. We do this on our developer box (where each account is given its own private repo which syncs against the DragonFly master repo). I don't bother optimizing my own personal copies though.

And one final thing to note... if the filesystem can de-duplicate data, having a lot of copies lying around is even less of an issue. I've never had to depend on de-dup... it's kinda hard to actually run a 2TB drive that isn't being used to archive media files out of space... but it does work particularly well on backup machines.

-Matt

Re:It's because

[Anonymous Coward]

I'm posting/replying anon because I've never bothered to make an account here.
In my experience perforce is the industrial strength RCS. It ain't cheap but it handles what you need.
I used to program video games.
The source assets include code (order of magnitude: about size of the linux kernel), art data for multiple consoles and ALL the binaries needed to build everything.
All assets are in RCS as there are many code changes tied to art assets, they need to be in sync.
A well set up work environment relies on NOTHING outside of the project directories as you require mutually exclusive tool sets for different projects. Console video game development has many strict requirements on which SDKs you must use depending on the release date, which means you need isolated development environments for each project. There is also a requirement to be able to build a bit identical copy of the gold master for each SKU from your backup. Setting up your production system this way makes that possible without spending weeks tracking down the specific version of the tools you need (assuming that you remembered to archive all of the version information on the hundreds of tools needed to build a shipping product).
The last shipped game that I worked on had a minimum sync size of ~43GB. That did not include movies, design documents, style guides or multiple language support. That built the PC, XBox360 and PS3 SKUs. A full sync was well over 100GB which I never did as I didn't need that stuff.
Downtime is also an issue. If setting up your machine for production takes more effort than installing your favorite editor, the RCS system, syncing, then building with no other steps you're doing it wrong.
Yes, I have strong opinions. They are formed from over 20 years in the entertainment industry. I have seen thing go well and I have seen them crash and burn.
I'm sure git is fine for actual distributed development but I have never seen a company use that model. There NEEDS to be 'one true master' repository internal auditing.
We use git, svn and perforce (each for a different part of the code base ARRGH!) where I work now and git just does not allow the same flexibility as perforce. I want my multiple change lists and the ability to sync any file to any revision easily for testing. I want to be able to select someone else's change list and revert it locally without hassle. I just find that git gets in my way when I have shit to do and little time to do it.

Re:It's because

[buchner.johannes]

see "git clone --depth"

Re:It's because

[DrXym]

Perhaps some MS engineer can chime in but it seems highly improbable to me that their code is structured with one root and 50GB of crap underneath it. More likely it is broken into modules and submodules and most engineers wouldn't even bother pulling or building bits of the source that don't directly touch their area of responsibility. Most likely they just link to some debug / release binaries for the other stuff which is stuck somewhere on their network.

While git has the somewhat fortunate / unfortunate property of pulling a project in its entirety (i.e. you can't cherry pick folders like in CVS / Subversion), I would assume that anyone using it on a large codebase would choose to structure their projects alone sensible boundaries so there is no need to do this. Indeed if you look at Android (which uses git), that's exactly what it does with lots of git projects and a tool called repo which takes care of much of the drudgery of pulling & branching projects with one command. One could probably argue that git has some issues coping in large environments for repo to be needed at all, but the fact that android does use git demonstrates it can be used on large codebases.

Re:It's because

[mcvos]

Can SVN or any other version control system handle 50GB of code? I'd hate to see what synchronising with a repository of that size would look like.

Re:It's because

[Aighearach]

it does that stuff, try reading the friendly manual next time instead of whining and making up stories about 50G datasets and no money for network backups because you spent it all on perforce.

Re:It's because

[mfwitten]

All assets are in RCS as there are many code changes tied to art assets, they need to be in sync.

Perhaps git's submodule feature would be of service here. From the man page: 'Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit.'

The last shipped game that I worked on had a minimum sync size of ~43GB. That did not include movies, design documents, style guides or multiple language support. That built the PC, XBox360 and PS3 SKUs. A full sync was well over 100GB which I never did as I didn't need that stuff.

I wonder whether something like bup (which is based on git) might be useful for managing the large datasets; given that bup stores data in git repos, you could probably even use it as the basis for a submodule (perhaps with the help of scripts to unload the data where desired).

However, I think the main point is that git is optimized for managing code history and that it's kind of silly to expect git or any other tool to handle both usage cases well. When it comes to managing code history alone, git probably provides better tools than what you espouse:

I want my multiple change lists and the ability to sync any file to any revision easily for testing. I want to be able to select someone else's change list and revert it locally without hassle. I just find that git gets in my way when I have shit to do and little time to do it.

You can do all of these things easily with git's `fetch', `log', `whatchanged', `diff', `merge', `show', `checkout', `reset', `stash', `revert', `rebase', etc.

If there's on thing you can do with git, it's slice and dice code and revision history in any which way you please. Frankly, I think you're frustrated because you don't know what you're talking about with regard to git; you've never bothered to learn what you assume is an inferior tool. In reality, the inferiority is your mindset.

Re:It's because

[mfwitten]

You'd probably also like git's `cherry-pick'.

Re:It's because

[maxwell demon]

What about Mercurial?

Re:It's because

[shutdown -p now]

After CVS, any other source control system is the greatest thing since sliced bread.

Except SourceSafe, but we're getting into some hardcore BDSM here...

Re:It's because

[TheRaven64]

I don't think I've ever met someone who hates Mercurial, and that seems to be a pretty strong selling point. All other revision control systems seem to have some people who swear by them and some who hate them (except SourceSafe, which only has the latter), but I've not yet met anyone who has used Mercurial and ended up hating it.

Re:It's because

[melikamp]

Git this dude some mod points already.

Re:It's because

[gbjbaanb]

I do!

You'll find a lot of corporate type environments have this much code (and other artifacts) in their SCMs, partly because they store lots of stuff, partly becuase of the large amount of history.

SVN handles this well as you can cherry pick pieces to checkout - google 'sparse directories' for details. You have to split your repo into submodules or separate projects when using git.

Re:It's because

[gmueckl]

I can't tell you about 50GB of data, but I've had a repository with 10GB worth of text files and it worked like a charm. Sure, checkouts would take forever, but with the huge number of files this was expected. The repository never broke.

And to be honest, 50GB of source and data for a game sounds quite modest to me if this includes all the data in the respective source format (Photoshop, Maya/3dsmax, ...).

Re:It's because

[Xtifr]

I don't hate Mercurial; it's an excellent system overall, but I've certainly sworn at it a few times for its obtuse, only-one-way-to-do it approach that may or may not mesh with your needs or workflow. There are hacks available to get around most of its weaknesses, but in many cases, they feel like hacks. Git is a whole lot more flexible, which is of course both a strength and a flaw if you want something that just works with minimal effort or thought.

Re:It's because

[brantondaveperson]

Git is superior to svn.

But it's also a massive pain in the arse, whereas svn is simple and elegant.

I had a crack at git once, and what with the terrible windows support, long hash strings for revision numbers, millions of obscure commands, I just gave in. I mean really, what is the point? I just want to write code, not faff around with overly tricky tools.

Not to mention the fact that I didn't see any advantages with merging. If two people change the same lines in the same files, git and svn both freak out in just the same way.

If someone could explain to me in what way git is so much better at merging I'd love to know.

Re:It's because

[gmueckl]

Oh? Then you can certainly tell me how you can manage different access rights for different users/user groups on different parts of a repository (hint: they may and will change over time). We need to be specifically able to deny any access or write access to any path/file within the repository. SVN does a really nice job there. Certainly you can point me to another version control system where there can be a central server hosting some 400 repositories and watching over the access rights. Such a system would be instantly considered as a possible alternative here.

Re:It's because

[Anonymous Coward]

Perhaps some MS engineer can chime in but it seems highly improbable to me that their code is structured with one root and 50GB of crap underneath it. More likely it is broken into modules and submodules and most engineers wouldn't even bother pulling or building bits of the source that don't directly touch their area of responsibility. Most likely they just link to some debug / release binaries for the other stuff which is stuck somewhere on their network.

Not a softie, but I can attest that pretty much all centralized systems are split somehow to avoid having a single huge repository. Developers are not really much involved in the decisions - most systems allow to checkout only what developer needs, even from multiple repos. (Git's way is the submodules, but in practice it is not much different from other VCSs.)

Otherwise, a single huge repo has piles of administrative problems: it's pain to manage, it's pain to replicate, it's pain to backup and it's pain to recover if needed. Thus source code/etc is kept in several repos. When a new very major release is planned, the snapshot of old development repos is copied into new repos, where the new development starts (think of "no return branching," stripping all the history). But e.g. documentation and release support infrastructure live in their own repos, shared by all releases. IIRC our admins try to keep all repos below 10GB, and when needed advising a move to new repos during the new release planning.

While git has the somewhat fortunate / unfortunate property of pulling a project in its entirety [...], I would assume that anyone using it on a large codebase would choose to structure their projects alone sensible boundaries so there is no need to do this.

I do not have experience with Git in commercial development, but in private usage the problem is largely non-existent: in single Git repo you can literally have unlimited number of private/local branches and you can switch between them effortlessly. With most commercial centralized systems one generally ends up pulling every release version into a separate directory, what from disk space perspective (on networked backed up home directories) is a PITA of its own.

Re:It's because

[mfwitten]

* Any abbreviation of a hash string will do as long as it's unique among the hash strings known to your repo.

* Use tags instead of hashes.

* Use branches and their names effectively.

* Use git's `name-rev' command.

* Read about the other ways to specify revisions.

* You only need a handful of commands to use git for the vast majority of the time: checkout, log, pull (fetch and merge separately can be nice), rebase, add, commit, reset.

What's your problem?

Git is superior to svn... But it's also a massive pain in the arse, whereas svn is simple and elegant.

You must be joking!

The conceptual underpinnings of git have been poorly expressed by many people, but they are utterly simple. If you understand pointers, linked lists, and hashing, then you understand git. My feeling is that you never bothered to reason about what's going on.

Re:It's because

[vlm]

I don't think I've ever met someone who hates Mercurial.

Everyone hates a VCS the first time it frustrates them. This only means practically no one uses Hg.

The key is which VCS, that they've used, do they hate the least. The answer almost universally seems to be GIT.

I use GIT as a distributed backup, sorta. I always had nightmares about losing the SVN server and all the backups (F5 tornado? Riots? Giant city eating fire?). I had offsite backup but only 5 miles away... With GIT all my deployments have a complete set of all development data. Disk space is cheap so I don't care. Also I can keep working when the LAN is having issues.

I hate GIT, don't get me wrong. Some of the syntax almost seems intentionally obtuse; No VCS is more appropriate for ESR's intercal compiler than GIT. I just hate GIT less than ... everything else I've used, and I think I've used all the open source ones.

Re:It's because

[Miamicanes]

> git is better than all the other VCSes

As long as you aren't trying to use it under Windows without Github or a real Linux system to fall back on for operations that just don't (quite) work yet with the Windows version. Two specific operations that come to mind are 'push' and 'rebase'.

Re:It's because

[maxume]

If you have really used *all* of the open source VCSs, it seems unlikely that you have actually used them to do anything.

Re:It's because

[wagnerrp]

Interesting, but the inability to push is a shame.

Re:It's because

[DrXym]

And IBM Rational ClearCase.

I had to work with it for 5 years and thought it was the most bloated, expensive, sluggish, over-engineered, counter-intuitive source control system I've ever had the misfortune to use. It's performance was so network bound that it was practically unusable outside of the same LAN as the server. Got teams running on two sites who need access to ClearCase? Tough you'll have to build two ClearCase servers, and hire two sets of admins to sync sites and sort out all the merge issues / build failures you're going to get keeping them in sync. Got workers who work remotely through a VPN? Tough they can't, except through a shitty thick client called ClearCase Remote Client.

I really pity anyone who has to use it. The funny part is a long time ago IBM had something called CMVC which was actually a pretty radical VCS with the concept of changesets, built-in bug reporting amongst other things. ClearCase to me stands a warning of what a source control system should not do.

Re:It's because

[rafe.kettler]

Most web applications and libraries are "small code repositories", so Git works admirably for those.

Out of curiosity, what handles such a huge codebase so well?

Re:It's because

[siride]

Git submodules and the git subtree add-on take care of a lot of that, actually. You can also do a shallow clone, so you don't get the entire history. I'll admit it's easier in SVN because it's the default (and indeed, only) way to do things.

Re:It's because

[cameroneagans]

That's still irrelevant because you wouldn't use Git for that anyways.

Re:It's because

[dr2chase]

I've never used git, so no opinion there. When I inflicted Mercurial on the rest of my team, they were not so happy at first. Principal gripe was: "you mean I have to type TWO commands to send my stuff to the server?" They seem to be getting over that.

The factors that drove our choice of version control system were not the ones I have seen discussed here. When we started out, I don't think Mercurial was quite ready for prime time, and none of us had heard of it, either. Some years back, we were looking for something to use for hosting our project, tracking bugs, etc, and Trac ended up as our choice (low-hassle, low-overhead) and that was how I first learned of Mercurial. BUT -- for an external website, I could not figure out how to (easily) secure external Mercurial access (on a box that was by-default only http-accessible, so no option to ssh in for Mercurial), so we did not use it. This was a case of theory meets practice meets impatient developer meets crap Apache documentation, but it ended killing the Mercurial option.

I DID, however, use Mercurial privately to mediate between two subversion repositories (because it was easy) and that got me hooked. Again, note that I pursued the path of least resistance -- if there's a clean way to do this subversion, then they have a TERRIBLE case of opaque documentation.

Later on, change in corporate ownership, change in internal IT practices, we were encouraged to move our stuff to Java.net. I looked, and lo, Mercurial or Subversion, and they handled the security for me, so we went with Mercurial. The two main advantages are (1) merging sucks less and (2) I can do local commits as I work. And we put all sorts of crap in our repository, because I am impatient, and pursue the path of least effort. A tool that works for impatient people, is a good tool. Reading things that translate as "the easy way is the wrong way (with this tool)" suggest to me that I would not be happy with that tool.

Re:It's because

[Archwyrm]

If you aren't merging, then you are doing it wrong. By the way, I hear that branching in SVN is extremely cheap!

Re:It's because

[Cutting_Crew]

i still am amazed that companies still want to pay IBM tons of money for things like rational rose and clear case. seriously only a very minute amount of companies need 10% of what clear case specializes in that other things like CVS, SVN or git cannot already do.

Re:It's because

[Yunzil]

Really? Because we recently switched from CVS to Git at my place of work, and I would happily go back to CVS immediately.

Re:It's because

[Haelyn]

Accurev does it, and makes it look easy.
A couple of years ago I was release mgr for a major US airline(two-vowel carrier code, same vowels) which uses Accurev for *all* its SCM. I don't remember the exact size of the storage set, but it was way bigger than 50GB and Accurev had absolutely no issues with that.

Not affiliated in any way with Accurev, just a satisfied user.

Re:It's because

[Haelyn]

(...)thought it was the most bloated, expensive, sluggish, over-engineered, counter-intuitive source control system I've ever had the misfortune to use. It's performance was so network bound that it was practically unusable outside of the same LAN as the server

Clearly you haven't yet had the pleasure of "working" with Borland Starteam.
I still wake up in a cold sweat every once in a while...

Re:It's because

[shutdown -p now]

Yes, really. If you don't understand the benefits of (at the minimum) atomical multifile commits, then I question how much you've really been using CVS (and the size of your project).

Re:It's because

[afidel]

You must have been doing it wrong since Cisco used/uses (I was there 2000-2004) Clearcase to maintain IOS across dozens and dozens of sites around the world. It is a resource pig though, for a hundred developers we had an almost fully loaded Sun Enterprise 4500.

Re:It's because

[KingMotley]

We do.

Re:It's because

[KingMotley]

Yes.

Re:It's because

[DrXym]

I wasn't in charge of administering it just using it. But I was aware that the company maintained a Clearcase repository on each of their sites - 3 in the US, 1 in Ireland and one 1 India. If we wanted to work on a project we'd have to go grovelling to the CC admin asking for a local branch and wait the half a day or whatever for it to be pulled. Each site had a team of admins who spent much of their time screwing around writing scripts keeping these things in sync. The amount of administration and expense to the company must have been obscene.

Trying to fetch a view from a remote server was so 1/100th the speed of a local operation. Since I worked remotely most of the time this was my daily burden and I tended to try and fetch my snapshots when I was on site.

The only respite was near the end of my employment when IBM Rational finally produced a remote client (CCRC) which made the experience barely tolerable. Clearly gave up trying to fix the fundamental issue and preferred to mask it with a proxy instead. Even then the client was quirky, bloated and slow.

The product is IMO a time sink, a money pit, and a drain on programmer's time & morale. It had such a debilitating effect on my development even in normal LAN conditions that I pity anyone who still has to use it. Though having said that my current place of employment uses CVS (horrors) so I'm pretty keen to move them to git.

Re:It's because

[m.dillon]

Well, I certainly was not expecting you to use RCS as a comparison point. RCS is utterly horrible when dealing with large data sets. Any modification to a file requires rewriting the entire rcs file and doing something like, oh, tagging, requires rewriting every single file in the repo. Every single one.

RCS is a very filesystem-heavy repo management system. Updates, checkouts, pretty much everything you do *except* single-file log displays are expensive. Such operations have to scan or access nearly every file in the repo and at least stat every file in the checked out tree. For large repos with hundreds of thousands of files RCS/CVS is nasty as hell.

Nor can you can you reliably mirror or replicate a RCS or CVS repo. Neither rsync nor cvsup are capable of reliably replicating a live, heavily used RCS/CVS repo. I've tried many times... I have to mirror the NetBSD CVS repo to get their pkgsrc into a git mirror and it takes a complex script to try to detect a point where the entire CVS repo is quiescent. Even with the quiescence check my script *still* has to do a full cvs checkout and an actual diff -r between the checked out CVS repo and the checked out git repo to catch occasional failures.

In short RCS/CVS is a mess. GIT is not a mess. With git you just use git-daemon and git:// URLs and you can get massive, reliable replication of the repo.

The only other issue involved here seems to be one of machine resources. But in today's world machine resources are cheap. Even a large 50G+ repo trivially fits on a sub-$100 2TB hard drive, and it takes only a moderately-sized SSD caching layer (~100G) to make the repo operations efficient. That's cheap enough that every developer can keep multiple full repos on their workstations.

In many respects the GIT concept has grown into its own by virtue of the greatly improved storage resources available on today's machines. In the 80's and the early 90's a centralized repo would have been far more important simply by virtue of the relative disk space required. In 2011 the relative disk space required for even a large repo is tiny.

-Matt

Re:It's because

[sciencewhiz]

I'm sure i'll get modded down into oblivion, but clearcase will do this. It won't do much else, however.

Re:It's because

[bored]

Yes, really. If you don't understand the benefits of (at the minimum) atomical multifile commits, then I question how much you've really been using CVS (and the size of your project).

Well to jump in here, CVS has warts, but nearly all of them are "tool dependent" or easy to work around. The problems with lack of atomic commits in CVS are mostly solved if a tool like bonsai is running against the CVS repository. The remaining problems are ones that aren't really solved in any of the "distributed" VCS's because they lack a way to exclude people from making conflicting changes.

The nice thing about CVS is that the file format is so simple and well understood that there are a metric crapload of tools out there, many of which reduce or remove problems associated with core deficiencies in the command line tools everyone generally associates with CVS. Furthermore, the format has been stable for so long that tools created ten years ago continue to work. For example, tkcvs provides a nice per file branch/commit graph with diffing that I want to cry when using many competing VCS tools.

Re:It's because

[bored]

git is better than all the other VCSes

Or at least its better than SVN, the previous darling of the open source movement. Frankly, its hard to imagine anything worse than CVS, but I believe SVN might actually take that cake. On the surface it sounds like such a bunch of good ideas, but the details quickly prove otherwise.

Re:It's because

[S.O.B.]

Because they can more easily write off the expense of vendor package/consulting and because management needs a vendor to blame/sue if things go wrong.

When you buy something like ClearCase IBM will help you install and configure it. They will also offer consulting services to customize. These expenses easily be identified (invoices, etc.) as a tax writeoff. An open source VCS will still require installation, configuration and customization but is more likely to be done internally and is harder to identify as a tax writeoff.

The other issue is liability, for lack of a better term. Having a vendor standing behind a product is an important consideration for corporations if and when things go wrong.

FYI, I was technical lead on a multi-million dollar VCS replacement project that considered two vendor and one open source tool. The open source tool was only there as leverage against the vendors and was never seriously considered for the reasons I indicated above..

Re:It's because

[Yunzil]

Just several million lines of code.

Anyway, like bored said, you can work around the lack of atomic commits, but aside from that as far as I've been able to tell, git makes every single thing harder. And it's not just me. There are many of us that have multiple copies of the repository named things like "project.fucked", "project.fucked2", "project.wtfgit" because you typed the wrong command and git did *something* (and you can never quite tell what) and screwed up your directory.

Give me that old time religion^B^B^B^B^B^B^B^BVCS.

Re:It's because

[shutdown -p now]

I've never seen people jump from CVS directly to Git, so perhaps this is a typical sample of the issues... it certainly is a major paradigm shift. And, with Git in particular, it is needlessly made more complicated by its arcane syntax and strange choice of terms.

Have you looked at Mercurial? It's superficially close enough to SVN to provide for a smooth transition; and SVN, in turn, largely feels like "CVS done right". Of course, depending on the workflow in your team, it may well be that you don't need DVCS in the first place, in which case SVN is probably the best choice. But I don't know of any good reasons to stay on CVS (other than "that's how we did things in my day, now get off my lawn" ~).

Re:It's because

[Yunzil]

The funny thing is, we went to Mercurial for about 2 weeks, and then went to Git. Somebody made a mistake with Mercurial and messed something up, so the decision was made to go to Git. You know, because it's impossible to mess anything up with Git. :-b

Re:It's because

[jon3k]

so you mean git is only good for 99.999% of all software projects? oh well, i guess it was a good try, everyone back to subversion!

Re:It's because

[jon3k]

I highly doubt microsoft is dumb enough to give that many people access to the entire source code tree to windows, which is what I presume we're talking about here? or any single product I suppose. that would be crazy.

Re:It's because

[Thuktun]

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

That does get some getting used to, but pulling a git clone is incredibly fast compared to a simple SVN checkout, particularly if you're using a repo hosted over WebDAV.

I used to scoff at Git, but I've really become a believer.

We have a five year old Java project with close to 6000 commits against it hosted in Subversion. The working copy (ignoring .svn directories) is around 336 MB, including build dependencies and test resources. The Git repository clone of the entire Subversion project is 423 MB, only slightly larger than the working copy. (I'm sure some of this is due to the dubious decision to host dependencies in the source tree rather than pulling them via Maven.) Since I usually had at least two or three working copies checked out with Subversion to work on branches, I basically broke even on disk space moving to Git as a front-end for Subversion.

From my experience, the Git toolset's effect on my productivity would have more than made up for an increase in disk space, anyway. It makes many things much easier and just works. (Which they often did not in Subversion. I got sick of blowing away and re-creating Subversion working copies to fix bizarre problems in the working copy metadata.)

Re:It's because

[wagnerrp]

I develop for a 9yr old C++/Qt project with some 27k commits before converting to Git last December. We've got another 3500 or so commits since then. It was around 110MB for the Subversion working copy, but ballooned to over 400MB for the Git repository. Now the primary code base wasn't that big of an issue. A bit of use of git-new-workdir and having multiple copies in different branches was really no more expensive than it was with Subversion.

However, things like our Apache interface only took up a couple hundred KB. Our primary web dev was accustomed to having a whole bunch of different versions sitting around to test various things. With subversion, a couple hundred KB and a couple seconds later, he has a new copy downloaded. Git simply doesn't allow for such operation. Carrying 100+MB and having to spawn a new branch just to test something out can be a big nuisance. In order to continue working in the manner he wanted, he had no choice but to split off into a different repository.

Git certainly has its uses, but it has its pitfalls too. There is no one-size-fits-all solution to anything, and Git is no exception.

Github?

[Sorthum]

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?

[Netshroud]

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

Re:Github?

[Microlith]

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?

[Jimbookis]

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?

[Stewie241]

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?

[Tumbleweed]

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?

[Anonymous Coward]

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?

[mgiuca]

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 and ended up with 88 comments including meme images.

Re:Github?

[MemoryDragon]

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?

[Tacticus.v1]

Such an awesome commit :)

Re:Github?

[ls671]

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 ;-)

Re:Github?

[grcumb]

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.

Well, I guess that leaves the porn site. I'm going to call it... <pimp voice>GitItOn</pimp voice>!

Re:Github?

[Antity-H]

+1 : github is pure awesomeness, that and gists: pure genius. If I were to recommend implementing git in a corporate environment I would push for a private internal github installation (I am talking big corporate here) even though I don't have any stake in github.

I would also probably push for gitorious but haven't had time to properly evaluate that yet

Re:Github?

[Anonymous Coward]

You forgot the travel web site called GitTheFuckOuttaHere

Re:Github?

[Anonymous Coward]

I'll call it GitFace! Who's in with me on the IPO in 2 years?

I'm preparing my lawsuit as we speak. I helped you create the site, as evidenced by this very post! I'm entitled to 50% of the company.

Re:Github?

[Guy Harris]

This may be due in part to the way github integrates social networking and coding

[ +1 ] <[70]

[w> Follow] @{projectname}

[mnIn Like] [f] 375 people like this commit.

{shudder}

Re:Github?

[gbjbaanb]

There's the relatively new ubersvn which is a 'install in one go' type system that also adds a loads of additional features including a 'social hub'

Re:Github?

[Anonymous Coward]

Uh, BitBucket?

Re:Github?

[yarnosh]

If nothing else, it is just handy to have a free/cheap place to publicly (with the option of privacy) host your repository that is user centric rather than project centric. Even without the social aspects like easy forking and such.

Re:Github?

[Tumbleweed]

> Well, I guess that leaves the porn site. I'm going to call it... GitItOn!

And the redneck porn site: GitErDone

Re:Github?

[Anonymous Coward]

Like git and github.com, Bazaar has launchpad.net and mercurial has bitbucket.org. And berlios supports lot of version control systems...

Re:Github?

[seantide]

I don't know what the award is precisely, but you won it... :)

GitHub

[Anonymous Coward]

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

Bazaar

[mgiuca]

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, which I wrote a rebuttal of at Why Git Ain't Better Than X.

Re:Bazaar

[Anonymous Coward]

> 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)

Re:Bazaar

[nschubach]

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

[Anonymous Coward]

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

[mgiuca]

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

[mgiuca]

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 (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

[bgat]

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

[euroq]

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

[mgiuca]

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

[Anonymous Coward]

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

[MemoryDragon]

Bazaaars biggest problems was/is speed.

Re:Bazaar

[byronblue]

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

Re:Bazaar

[mgiuca]

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

[mgiuca]

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

[m.dillon]

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

[petermgreen]

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

[caniszczyk]

Git does have commit metadata... and for awhile now... see git-notes... http://www.kernel.org/pub/software/scm/git/docs/git-notes.html http://progit.org/2010/08/25/notes.html

Re:Bazaar

[mgiuca]

Someone already mentioned this. I'll paste what I said above there (and it's backed up by your second link too, see the section "Sharing Notes"):

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 (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

[euroq]

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 tend think the argument "I haven't learned it yet" isn't a good argument. Also, URLs identifying branches is syntactic sugar which doesn't affect the underlying system of the repository. The idea of only accessing one at a time has merit, but if you need that (like I do sometimes) you simply create two workspaces or checkout the files to a separate folder, both of which end up having the same effect as the Bazaar solution.

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").

This happened to me at a previous company using SVN. It had to do with the fact that a build system built several projects. I don't remember why... I suppose they were separate directories which had individual trunk/branch/tag directories (module1/trunk and module2/trunk). If you tried to build a tag or branch, it was in one directory up past trunk (i.e. module1/trunk/project vs module1/tag/v1/project). You literally had to copy the subdirectory to the parent directory for it to build properly.

But anyways, this point wasn't BZR vs Git vs SVN, it was that I simply don't think having separate directories for tags/branches is a good idea due to the way it affects the underlying existing "metadata" on the file system, which is directory paths. On top of that, I hated having to take up so much damn space on the drive if I wanted the entire repository (which never actually happened when I was dealing with SVN, because it was too hard).

Another important point: you say that "trunk vs merged" in Bazaar is equivalent to Git, but it isn't.

I don't think I said that, and anyways I don't think that.

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

This is wrong. One can. The commit 83c7 and the commits e337 both would clearly state which tags are their parents: 83c7 would say "branch1" and e337 would say "release1.5", for example.

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.

It does know where commits come from. The only reason the user wouldn't know is if the branches weren't labelled (i.e. tagged). In my own professional experience (admittedly only the course of 2 years and a handful of Git repositories, two of which was very large), this has never happened. I guess that in Bazaar, the mere creation of a branch makes the branch automatically labelled at its origin. However, the end result of my experience in Git is that branches are also labelled.

This all being said, I am not saying Git is better than Bazaar at all. I definitely don't think Git is the end-all solution for VCS by any means, and it does have its share of problems. Most of my comments above are opinions, and I would think myself very rude if I said to you or anyone that such opinions are "right" instead of "what I prefer".

Re:Bazaar

[euroq]

Your cite branches in separate folders as a superior feature? Subversion has that crap and it's messy.

High five brah! I hated that shit when I had to use SVN.

You also mention "revision numbers" as a feature. Who gives a crap about revision numbers?

As a person who has professionally used Git (and likes it) in many repositories, both large and small, I miss revision numbers. When I e-mail my colleagues about commits (i.e. revisions in another syntax), it is annoying to communicate it: I have to copy and paste the entire commit metadata (name, author, date-time, and SHA) in order to reflect it properly. I would much rather say "15.1" or "newfeaturebranch.3".

It also has been a problem when using the "Blame..." tool to track down why something was changed, as you have to do a double-lookup to find the SHA of the changed line and then the commit of the SHA. Well, my bad because really you'd have to do the same thing with a revision number, but trust me... I'd rather be working with revision numbers than SHAs because it would be easy to know that this line was changed because of "newfeaturebranch" rather than e93f02a09f9fe092a039a923.

Obviously, we don't need revision numbers... but boy would I love to have them.

Re:Bazaar

[Anonymous Coward]

Bazaar's biggest problem is that I've never heard of it until now.

Re:Bazaar

[Anonymous Coward]

Not sure how it feels now, I think I tried bazaar when it was 1.4.x and I couldn't commit non-english filenames due to unicode issues under macosx (python unicode error exceptions, yay). So I didn't even bother checking the rest if the tool that is presumably mature (after 1.x) can't deal with the files I have. Of course I see now the version is much higher, so I could give it a try, thanks for the reminder.

Re:Bazaar

[he-sk]

Does Bazaar have a staging area?

Re:Bazaar

[Anonymous Coward]

You've forgotten bazaar's main problem :
"slow as shit"

Re:Bazaar

[mgiuca]

I tend think the argument "I haven't learned it yet" isn't a good argument.

No, but "I've tried to learn it and it so far has confused the hell out of me" is grounds for an argument that something is hard to learn.

if you need that (like I do sometimes) you simply create two workspaces or checkout the files to a separate folder, both of which end up having the same effect as the Bazaar solution

Except with a major difference: Bazaar gives you the ability to have both checkouts share the same database, so it doesn't take up twice the amount of space. Git doesn't let you do this -- you'll have to create two full copies of the repository. (Ironically, this accusation is often made towards Bazaar by people who haven't heard of shared repositories.)

This happened to me at a previous company using SVN. It had to do with the fact that a build system built several projects. I don't remember why... I suppose they were separate directories which had individual trunk/branch/tag directories (module1/trunk and module2/trunk). If you tried to build a tag or branch, it was in one directory up past trunk (i.e. module1/trunk/project vs module1/tag/v1/project). You literally had to copy the subdirectory to the parent directory for it to build properly.

It seems like things weren't set up very well. I fail to see how any revision control system could deal with this. If you had been using Git, you wouldn't have had access to those branches at all. The build system should be contained within the repository, not outside it, so it shouldn't matter what directory the repository is stored in on disk.

I simply don't think having separate directories for tags/branches is a good idea

I may have misled you into thinking that Bazaar treats branches the same way as SVN: It doesn't and that would be awful. Subversion stores tags/branches as subdirectories of the repository -- that means you have them locked into a particular location. Bazaar stores branches as parent directories of the repository -- they are just ordinary directories anywhere you like on your file system which contain checkouts of a repository inside them (but unlike Git, they only contain a single branch, and if you want multiple branches, you create multiple directories).

This is wrong. One can. The commit 83c7 and the commits e337 both would clearly state which tags are their parents: 83c7 would say "branch1" and e337 would say "release1.5", for example.

Aren't you assuming that both of the parents have tags? Wouldn't the user need to manually tag the commits to get that effect? In my experience, most merges just show up as a single object with what looks like two randomly-named parents (I know they're hashes but that doesn't help me as a human).

Most of my comments above are opinions, and I would think myself very rude if I said to you or anyone that such opinions are "right" instead of "what I prefer".

Of course. I'm only saying what I prefer, but my main source of frustration is not that people tend to prefer Git over Bazaar, it's that a) they dismiss the other DVCSes out of hand without actually learning about them, and b) the usual reasons claimed for why Git is better are true of all DVCSes.

Re:Bazaar

[mgiuca]

It has a "shelf" which is much like the Git staging area, only reversed. In Git, nothing is committed by default unless you stage it first. In Bazaar, everything is committed by default unless you shelve it first.

This works the same in practice: if you want to commit only part of your changeset, first you shelve everything you don't want to commit, then commit, and then unshelve again. I find that I make far fewer "accidentally forgot to commit something" errors. (A friend of mine came all the way to work one day, realised he forgot to stage something in Git from his home computer, and then immediately left and went all the way home again.)

Re:Bazaar

[Anonymous Coward]

tortoisehg/mercurial is very, very popular in industry these days. it's good enough, does it's job. dunno wtf the ruby community mention in this article post is about though, except that ruby community is very vocal while being very.. well, unproductive compared to the noise.

Re:Bazaar

[Anonymous Coward]

Revision numbers become cumbersome when you are doing a distributed VCS. You're going to need some kind of extra identifier to see if you're talking about my revision 142 or your revision 142.

That's not a problem in a centralized VCS, where you have a server to handle revision numbers, making sure they are unique.

Re:Bazaar

[inglorion_on_the_net]

Good points, and I would really like to know which VCS is superior, after all.

The problem is, it's not easy to find out. There are a lot of people saying "hg is better than git", without backing that up with any arguments. That doesn't tell me a whole lot. Then there are people saying "hg is better than git" with some arguments I don't understand. And the same is true for other claims (that git is best, or that Bazaar is best, and what have you).

All I know is that git works for me, works for some really large and complex projects, interoperates with various other VCSes, is fast, and that I like it better than other systems I've used (Subversion, CVS and RCS). The only thing that I don't like about it is its treatment of empty directories.

Should I try some of the other DVCSes? I'm sure I should. That would probably be the best way to see for myself which one works best for me. However, git is good enough that, so far, I haven't bothered to spend the time to really dig into any other system.

Re:Bazaar

[euroq]

No, but "I've tried to learn it and it so far has confused the hell out of me" is grounds for an argument that something is hard to learn.

I agree 100%. Many of my professional team members have fucked up with Git. That being said... I suspect the problems my teammates have had is because distributed VCS is in general harder to grasp than centralized ones, and so I think my teammates would have fucked up with the other DVCSs too. I don't have any professional experience with Mercurial or Bazaar, so I can't compare that aspect or back up my guess.

Except with a major difference: Bazaar gives you the ability to have both checkouts share the same database, so it doesn't take up twice the amount of space. Git doesn't let you do this -- you'll have to create two full copies of the repository. (Ironically, this accusation is often made towards Bazaar by people who haven't heard of shared repositories.)

This sounds like an advantage that Bazaar has. Personally, though, I feel like if you only want to checkout parts of a repository, then the repository is too big. Modules deserve to have their own trunk/branches themselves. Once again, just opinion - and my point is completely moot if you're dealing with someone else's repository that's too big.

It seems like things weren't set up very well.

It wasn't. I hated it. I argued against it, and failed. I think it's terrible that a person would have to manually copy stuff after checking out a particular tag/branch. But with Git (or other VCSs), one could have checked out any tags/branches and the directory path wouldn't have changed. That's the main point I was getting at... separate directories changes pathnames.

Aren't you assuming that both of the parents have tags? Wouldn't the user need to manually tag the commits to get that effect?

Yes. A stable release simply has to have a tag... if it doesn't, this is beyond a discussion of comparison of VCSs, because you wouldn't make a stable release without a tag or some sort of label. As far as the branch goes, also yes... if it is a non-trivial branch, then it should have a tag or a branch label (usually in the form of "origin/branchname"). In my professional experience, all non-trivial branches either had tags or the "origin/branch" branch was still in the previous commit line before the merge.

.... my main source of frustration is not that people tend to prefer Git over Bazaar, it's that a) they dismiss the other DVCSes out of hand without actually learning about them, and b) the usual reasons claimed for why Git is better are true of all DVCSes.

Totally hear ya. I think that Git is a stepping stone to the next better thing in 5 years. It has drawbacks which could be solved (and apparently some of which has already been solved with Bazaar and Mercurial... but I'm not going to agree yet that Bazaar is the "correct" way either, yet :) And yeah, people tend to think what they already use is better, even if it's not the case. Tons of psych studies about this topic.

Re:Bazaar

[Anonymous Coward]

The principle problem with revision numbers is that they imply sequence. And the principle idea behind any DCVS is the D, which implies parallel development. Take a look at CVS' revision numbers across branching to get an idea why revision numbers are bad.

Moreover, in your example, simply saying "revision 15.1" would be meaningless. At the very least you need to specify which git tree contains that commit. And now assume that someone pulls from you, or you push your changes to a different repository. Should the revision number remain the same? If yes, then how do you propose to deal with a push from another branch that also contains "revision 15.1"? If no, how do you propose to track revision numbers across merges and pull requests? How will you know if your feature from "revision 15.1" has been merged to mainline already without searching the entire history for a specific (name, author, date-time) combination?

As for identifying a commit, you only need that hash. And that hash is guaranteed to remain the same across merges.

Re:Bazaar

[gbjbaanb]

For example, they take up a linearly larger amount of space on your local storage media when checking everything out

when you clone a git repo, you get everything checked out anyway, so you're not saving any space at all. This isn't like SVN's sparse directory feature where you can checkout partial repositories, with git you (practically) have to check it all out to use all its useful features.

the difference between a 2d representation of branches (ie everythign laid out flat in a directory structure), and a 3d one (ie 1 directory that has thebranches 'overlaid' on it) is just syntactic sugar. If you're ever trying to use relative paths between branches (and trunk is effectively a branch), then you're in a world of stupid.

Re:Bazaar

[Anonymous Coward]

I don't think you comprehend basic git concepts very well (which, incidentally, makes you entire rebuttal mostly crap, but I digress).

The bzr shelf is nothing like git staging, in reverse or otherwise. If you want an aproximate analogy, it vaguely resembles git stash. Except it's not used for the same purpose, but rather as an awkward way of working around a crippled commit system.

One of the core values of git is having very good commit bundles. To this end, it allows you to prepare each commit carefuly and even modify them after the original commit (as long as it's still the head commit with nothing on top of it). This is why it has the staging area, where you explicitly add and prepare stuff for a commit.

The git stash is a way of putting aside a bunch of modified files quickly and temporarily, without losing the changes, while you do other operations which would affect those files (branch switching etc.)

Bazaar has "commit everything" by default ie. no concept of commit staging. On top of this, it has slapped the shelf as an awkward exclusion mechanism. That's all there is to it. It's neither stash nor stage and I find it to be an inferior system overall.

Please consider that there might be practical reasons why less people use Bazaar as opposed to git or other VCS.

Re:Bazaar

[he-sk]

From what I've read in your rebuttal posted up-thread, it's not really the same. It's more like "git stash" and "git stash apply" which seems somewhat brittle to implement partial commits. But I'll concede that one might get used to both workflows.

You strongly disagree with partial commits conceptionally, but as I've commented on your blog, not every repository contains code and not every code is tested.

IHMO, the staging area is git's killer feature which sets it apart from other distributed VCS.

Re:Bazaar

[mgiuca]

You strongly disagree with partial commits conceptionally

What do you mean by "partial commits"? I certainly believe you should make small logical commits and if it means you need to commit only part of your changeset, you should do that. What I said on the blog was that I prefer shelve/stash over the index/staging area, because shelve physically hides the changes so you can test that things still work, whereas the index allows you to create a commit with a file state that has never existed on disk -- that's what I disagreed with.

But anyway, I have been convinced in the past that the index is genuinely useful in certain situations (e.g., if you changed a comment, or if you changed a document that isn't code, such as HTML or text, and you know for sure that it isn't going to break anything). I would be delighted if Bazaar were to add this feature. But I disagree that it should be the default -- it is highly confusing, especially for people who have used other VCSes, that you ask it to "commit my changes" and it does not commit all of them. Git has a "commit -a" flag, which auto-stages everything. I would suggest that this should be the default, and another flag, "commit -i" or something, should commit just the index.

Re:Bazaar

[mfwitten]

Except with a major difference: Bazaar gives you the ability to have both checkouts share the same database, so it doesn't take up twice the amount of space. Git doesn't let you do this -- you'll have to create two full copies of the repository. (Ironically, this accusation is often made towards Bazaar by people who haven't heard of shared repositories.)

Local clones of a git repository use hard links by default in file systems that support hard links, so they are not two full copies.

Also, there is the git concept of an `alternate object database', which allows two repositories to share the same data.

Basically, Bazaar has no advantage here.

Re:Bazaar

[mfwitten]

Revision numbers (git doesn't have them, but other DVCSs do) are meant for local usage; universal names like git's SHA-1 names are what are meant to be used uniquely across any repository.

Re:Bazaar

[Anonymous Coward]

Your rebuttal's only feature that it claims is better than git is when it talks about bzr shelve like it's the be-all-and-end-all.

But wait. You forgot about git stash. You almost had a point there, but now it's back to deuce.

Re:Bazaar

[mfwitten]

In git, the first parent (e.g. HEAD^ or HEAD^1) is the commit into which the second parent (e.g. HEAD^2) was merged.

Re:Bazaar

[mfwitten]

Why do you NEED to copy information other than the SHA1 in order to reflect the commit properly? Also, why can't you just use shared tags to make it easier to discuss particular commits?

Moreover, you don't need to type in the entire SHA1; any abbreviation will do as long as it is unique among the other SHA1s known in the repository.

Re:Bazaar

[mgiuca]

Ah OK, cool.

Re:Bazaar

[Anonymous Coward]

Upvote.

p.s. Slashdot really needs an upvote button, even it doesn't actually do anything.

Re:Bazaar

[Anonymous Coward]

Bazaar is too slow to be taken seriously.

Re:Bazaar

[devent]

"for example a revision number is superior to a SHA not just in an opinion, but in a quantifiable way. "

Can you give an example why? In my opinion a SHA hash has many advantages vs. a number. For example, with a SHA hash I can be sure that a branch/commit/tag/file/repository that I have is the same that you have; you can't tamper with the files/commits; It gives a warrant that the file is correct at the disk after a crash;

The reason for a continued number are only: you have the time line in the numbers, and shorter IDs (but in Git you can just enter the first 5 SHA digits). But do you really need to known that the commit 45676 has come before 45677? After a big enough number it's like a SHA hash anyway.

Re:Bazaar

[PeterBrett]

Except with a major difference: Bazaar gives you the ability to have both checkouts share the same database, so it doesn't take up twice the amount of space. Git doesn't let you do this -- you'll have to create two full copies of the repository. (Ironically, this accusation is often made towards Bazaar by people who haven't heard of shared repositories.)

git does allow you to do this, with plenty of flexibility: see man git-clone. Specifically, if cloning a git repository on the same filesystem, the common data is automatically shared using hard links (don't forget that all entries in a git repository are immutable, so this Just Works); additionally, you can use some combination of the --reference, --shared or --no-hardlinks options to control exactly how cloning should occur.

Perhaps it would have been better to say "I don't think git allows you to do this" rather than "git doesn't let you do this". ;-)

Re:Bazaar

[Chemisor]

One reason is that Bazaar and Mercurial are both written in interpreted languages rather than C. Python is fine for an occasional one-off script, but a frequently used application written in it is not acceptable. The overhead adds up and becomes too annoying to ignore.

Re:Bazaar

[m50d]

Moreover, you don't need to type in the entire SHA1; any abbreviation will do as long as it is unique among the other SHA1s known in the repository.

This is really useless though. How can I know a given start will be unique? So how do I know how long is long enough to be safe to email to bob (who has his own set of local commits, whose SHA1s I don't know)? So I end up just using the whole thing every time.

Re:Bazaar

[Anonymous Coward]

Meh, bazaar can't even resume interrupted checkout which is painful for large project. There's nothing more than annoying when user need to redownload the whole thing again when disconnected during download transfer.

Re:Bazaar

[mgiuca]

Perhaps it would have been better to say "I don't think git allows you to do this" rather than "git doesn't let you do this". ;-)

Perhaps ;) But I was replying to a comment that said that Bazaar branches "take up a linearly larger amount of space on your local storage media when checking everything out", so I afforded the same level of self-surety as the original comment.

Re:Bazaar

[mgiuca]

I'm sorry, you lost me at "Python is fine for an occasional one-off script." Do you actually think that nobody uses Python for serious applications? I still find the talk of Bazaar being slow a slightly incredulous. I think it has a reputation of being slow from five years ago when it was. I have used Bazaar for every project, small and large, for the past three years, and have never once had to wait for any noticeable period of time.

I accept that Git is faster, but when you're talking about a hundredth of a second versus a tenth of a second, you're really just arguing for the sake of it.

Re:Bazaar

[Anonymous Coward]

Why can't you just write a script that checks out a git repo, copy it, remove all the .git folders, then check that in to your bazaar repo? Then another script that does the same thing, in reverse. You can even make it grab all the history between the last revision it checked out from repo A, and all the commits since then in repo B, then put that as your commit message when checking into the master repo!

I don't know bazaar, but I'm assuming all the information you would want is available through the command line, thus you can build your own bridge between the two repos. Sure it's not as easy as a one line command, but it's not that's hard either.

Re:Bazaar

[Anonymous Coward]

Performance and ideological issues aside, one problem with Bazaar is marketing and support.

I've never heard of Bazaar before, and just now from this thread I finally realized what those bzr checkouts were for. I just never associated the two together.

Git is used for the Linux kernel, and heavily pushed by Linus. He wrote the damn thing, and he's the primary market spokesperson. When he talks about needing to merge 8600 commits, people pay attention to what SCM he's using even if he's not explicitly pushing it.

I had to Google for "Who Uses Bazaar?". While I recognize a lot of those projects, this is the first time I hear Bazaar mentioned.

Git has gotten popular enough that Google Code decided to add Git support despite already supporting Mercurial, which brings me to another point.

GitHub is the Facebook of online source control hosts. They have neat tools and a great social system built in.

I looked up source control hosts for Bazaar. There's Launchpad (no surprise there) and Sourceforge. I must have missed the memo, because I thought Sourceforge only supported Subversion. It feels like Bazaar has no marketing whatsoever (to be fair Sourceforge also supports Git).

That is why all performance items being equal, I don't see Bazaar overcoming Git anytime soon. Let me know when they get some publicity like Linus' Git presentation at Google Tech Talk.

Re:Bazaar

[shootmeagain]

There is Eclipse plugin for Bazaar but it's not so good. It became the reason I finally tried git. That's not Bazaar's fault. To me git is a DVCS with attitude. Many git users I know seem pretty fucking proud of themselves for using git, I don't know why. That's not git's fault. Now that I tried, I really like git, but I will stick with Bazaar unless at times when I really need the Eclipse plugin.

Re:Bazaar

[Chemisor]

Do you actually think that nobody uses Python for serious applications?

Oh no, of course some people do. I was merely claiming that I would not use a Python application for anything, unless I have no alternative (I'm looking at you, Calibre). The interpreter overhead is unacceptable.

I accept that Git is faster, but when you're talking about a hundredth of a second versus a tenth of a second, you're really just arguing for the sake of it.

Hardly a tenth of a second. We're talking about seconds for some operations. git is always instantaneous. bzr often exhibits very noticeable (>1s) lag. It can be even worse in more substantial applications. Calibre, for example, is a Python application and is way too slow for what it does. If there was a compiled app with that functionality I'd switch right away.

Re:Bazaar

[Anonymous Coward]

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.

I've used a lot of version control systems. Git does what I need it to do in order to get work done - no more, no less, and is well supported. The features you enumerate as superior to Git don't strike me as being particularly useful or necessary, especially the "commit metadata", which you define as crucial: since most projects settle on a single version control system, your "crucial" point is automatically made irrelevant.

Anyway, there are two possible conclusions to draw: either Bazaar really is significantly better than Git, which means you're doing a very poor job of communicating just how much better Bazaar is (and why); or, Bazaar is (technically) worse or only incrementally better than Git, which means it's unlikely to ever gain enough traction to achieve a significant market share/support, and will stay a niche player in the DCVS arena.

Re:Bazaar

[dmpot]

the only thing it has going for it is a larger community

Not just a larger user active community, but also larger and more active developer community. It means that even you can find some similar features in Hg or Bzr, they are available as additional plugins, which are less tested and do not get the same support as core features.

I've argued to wit's end that Bazaar is superior to Git in a multitude of ways

Well, same things can be advantages in one but disadvantages in another, because it depends on your workflow. If you try to stick to SVN-like workflow, Bazaar probably works better, but if you try to use a workflow that more similar to what Linux kernel developers use, you will see that Git is _much_ better -- it is more intuitive and all defaults are right for that case. Then some other features like "explicit moves/renames" may sound great for novices, but it does not work well in truly distributed workflow. If every branch gets merged to "trunk" of the central repo, it is not a problem. However, this is not a distributed workflow (just being able to work offline does not make it distributed). When you try to work in really distributed fashion, things can be merged in different directions before ending up in the upstream, the history graph is far more complex and your explicit tracking does not work well. Linus had this experience with BitKeeper, which had explicit tracking for moves/renames, and one lesson that he learned from it was that explicit tracking introduces more problems than it solves. So, by design, Git does not explicitly track rename/copy but uses heuristic instead.

Git lacks commit metadata

This is not true. By definition metadata is "data about data", and Git stores its own metadata in the commit object, but it does not store foreign metadata. There is two reasons for that. First, Git may not know how to deal with them during some operations (e.g. git-rebase). Second, Git does not hide anything from the user. If you want extra information, you can store it in the commit message, in additional file, or as git-notes. However, if this information does not make sense to the user and only necessary for inteeroperability, you should store it separately as git-svn does.

it is impossible to meaningfully use any other revision control system in conjunction with Git

What about git-svn or hg-git?

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]."

IMHO, Bazaar got all its defaults for _centralized_ (SVN-like) workflow, but with ability to work offline on feature branches. However if you try to work with many repositories and with many small features branches, which oftentimes take months before they are merged to the main upstream branch (during which they go through a few intermediate merges and internal testing by other developers), you will see that Git handles this case much better. Most people who complain that Git is difficult or not intuitive just have not grasped _distributed_ workflow. Once you have understood distributed workflow, everything in Git becomes very natural. Mercurial is close to Git in this respect, but Bazaar appears to be counter-intuitive.

Re:Bazaar

[kabloom]

Bazaar allows more different types of workflows than git does (like the Subversion workflow, as you mention). My main problem with bazaar is that when I wanted to convert the SVN repository that holds my whole home directory about 5 years ago to bazaar, bazaar choked and git didn't. Now I'm using git, and even if they fixed my problem (or more likely the problem is moot), I see no reason to change.

Re:Bazaar

[npsimons]

Yet another DVCS article that doesn't mention Bazaar at all.

Well, in all fairness, the article is entitled "The Rise of Git".

And I know that performance isn't everything, but for some of us who run git everywhere to track our home dir (see the end of that article) kind of find the performance of git to be pretty nice. Other people have come to similar conclusions.

Re:Bazaar

[klapaucjusz]

Yet another DVCS article that doesn't mention Bazaar at all.

Neither does it mention Darcs, Mercurial or GNU Arch.

-- jch (who prefers Darcs himself, but has been switching to Git for compatibility with the rest of the universe)

Re:Bazaar

[Anonymous Coward]

"The only thing it has going for it is a larger community"... wow, that's it? Widespread understanding and adoption leading to a robust culture, ecosystem, and economic opportunities for those who embrace the tool?

For a while, I liked Mercurial better than Git (and on some level, I still do). But Git is popular, and that matters... a LOT.

Re:Bazaar

[Anonymous Coward]

"...because Git lacks commit metadata,"

Are you sure you are familiar with Git? Are you sure you just don't like it and therefore haven't really looked into it?
Because I know you can store metadata with commits.

Re:Bazaar

[euroq]

when you clone a git repo, you get everything checked out anyway, so you're not saving any space at all. This isn't like SVN's sparse directory feature where you can checkout partial repositories, with git you (practically) have to check it all out to use all its useful features.

No. With Git you have the entire database in a compressed form, and only one copy of the file system checked out. With SVN, if you get the entire database, you have ALL file structures checked out, i.e. you have every tag and every branch present on your local hard drive. Yes, I understand that most people wouldn't check everything out with a large SVN repository.

Also, just go to any open source repository that has a mirror Git and SVN repository and check them both out (as I have done for various reasons). The SVN repository always takes up more space. For example, try libgdx... the SVN repository took up 33% more space on my hard drive.

If you're ever trying to use relative paths between branches (and trunk is effectively a branch), then you're in a world of stupid.

As I stated elsewhere, I also thought it was stupid. But the company did it because that's how all SVN is setup... use trunk/branch/tags directories.

Re:Bazaar

[euroq]

I gave examples elsewhere. One example is communication with other people, as in when speaking or e-mails. Another example is when using the Blame... tool, you can see that this line was changed with "mybranch-3" instead of having to look up "ec09302930293".

For example, with a SHA hash I can be sure that a branch/commit/tag/file/repository that I have is the same that you have

Revision numbers only work with a master/centralized repository, and not with decentralized repositories as Git was designed for. However, I've never once dealt with a Git repository that didn't have a "master" or centralized repository. And if you could assign such a repository as the master one (which you can't do in Git now), the master repository could assign revision numbers.

Re:Bazaar

[mfwitten]

In practice, this is not a problem; if you're concerned, use tags. Also, consider git's `name-rev' and `describe' commands.

The problems you present are really not problems at all.

Re:Bazaar

[svick]

One example is communication with other people, as in when speaking or e-mails.

Isn't that exactly where version numbers in DVCSs fail? Yeah, you can talk about a revision 42 in your email, but when the other person tries to look at it, he will see completely different revision.

Re:Bazaar

[euroq]

Elsewhere I mentioned that this requires a central/master repository. Revision numbers aren't replacements for SHAs, they are simply labels. Such as "10th commit since branch1". The revision number is only assigned on the master repository, so local repositories with commits that haven't been pushed to the master server don't even have such a revision number. Also, it is fully expected that the revision numbers would change if rebasing or cherry picking occurred which erased history on the master server, but this is what you get when you erase history (i.e. force push). Force pushing already erases history so it is expected it would renumber revision numbers.

Re:Bazaar

[mgiuca]

If I were to use a revision control system to archive my home directory, I would probably choose Git too. It is a very good versioned file system. I would prefer Bazaar over Git for an actual software project.

Re:Bazaar

[mgiuca]

Well it certainly mentions Mercurial -- it dismisses it as irrelevant at several points in the article. Fair point that it doesn't mention the other ones, but I thought Bazaar was big enough (with the full Ubuntu community behind it) to at least warrant a mention.

Re:Bazaar

[mgiuca]

Then some other features like "explicit moves/renames" may sound great for novices, but it does not work well in truly distributed workflow.

Wow, I am offended that you consider me to be a "novice". I have never heard this argument before: the old mantra "explicit is better than implicit" applies here -- usually it's argued that implicit may sound great for novices, but it doesn't work well having a heuristic in the large scale, and if you have people who know what they're doing, explicit is far better.

I don't follow your argument at all. I use Bazaar's branching and merging extensively -- I have branches on branches and I merge every whichway imaginable. You're going to have to justify your statement that when "the history graph is far more complex... your explicit tracking does not work well". In Bazaar, you say "file A was renamed to file B." It doesn't matter how many branches or merges that change propagates through, or in which direction, it still remembers (because you told it) that that file was renamed. All changes made to the file in any branch, regardless of whether the changes were made to the file when it was called "A" or when it was called "B", are merged correctly. I have never encountered such a problem, nor can I imagine a situation in which a problem might arise (assuming you correctly told Bazaar that the file was renamed in the first place). With Git, on the other hand, you have to hope that the rename detection has works, and it is especially poor across merges. Even the expert cannot help in certain situations. I have encountered this problem on small trivial examples as well as on large repositories. The following is all that is required to trigger a complete merge failure on Git:

1. Create a repository with a file "A" in it,
2. Create a second branch,
3. In the branch, modify the file extensively (about 50% of the file). To make it more realistic, do it over, say, 10 commits instead of just one (this voids the argument "you shouldn't be changing so much in a single commit"),
4. In the branch still, rename the file to "B", and commit the change,
5. In the master, modify the file just a tiny bit (one byte should do it),
6. Merge from the branch to master.

You will find (if you changed the file enough in step 3) that Git hasn't detected the rename, so instead, there is a merge conflict in "A" between the change made in step 5 and the deletion of the file (Git keeps the file around and says "Deleted by them"). There is no conflict in "B"; it's just a new file. Now the user must manually merge the files "A" and "B", because Git hasn't even attempted a three-way merge. I tried this example using both Git and Bazaar. With Git it happened exactly as I described. With Bazaar, because I explicitly told it about the move, the three-way merge worked perfectly.

I would like to hear some examples of where explicitly specifying moves breaks things. I can't imagine how it could possibly be a problem, and all you've said is "it doesn't work well".

This is not true. By definition metadata is "data about data", and Git stores its own metadata in the commit object, but it does not store foreign metadata. There is two reasons for that. First, Git may not know how to deal with them during some operations (e.g. git-rebase).

Exactly -- it doesn't store foreign metadata. That's the problem: Git is hostile to foreign VCSes. Why shouldn't git know how to deal with them during some operations? Bazaar stores foreign metadata and it tracks it perfectly fine. You mention rebase: that's actually an exception. The reason a foreign VCS needs to store metadata is to make sure the same commit object contains exactly the same data. When you rebase, you're creating a commit object, so it's fine if Git were to drop the metadata at that point.

if this information does not make sense to the user and only necessary for inteeropera

Re:Bazaar

[gbjbaanb]

that's not surprising - you checkout the git repo, whereas svn you checkout the parts you need. If I copied the svn repo directly to my PC, it'd be smaller. Still, that's not the point - you should see our main repo at work, its huge as it has many years of history in it. With git, that's be a 40gb download. With svn, I ignore 90% of it. That was my point and the common usage of both.

Not that its a disadvantage per-se, the clone model has many advantages, but they become less relevant as your repo grows.

As for your work svn layout.. poor you. I'm sure people who think like that could find ways to screw up your git repo too. Just be glad they're not using an expensive, 'enterprise' tool for this. You could have the pain of a really wonky layout *and* the pain of Dimensions or PVCS :)

Re:Bazaar

[walshy007]

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.

So... should we put the metadata in for every single external client every other random person uses? Who cares if others using bzr can't see the bzr style merge history with the svn repo at all. I for one don't. The only thing I see happening is trying to mash together some superfluous system putting data that will never be used by the majority of cases and is not necessary into the repository.

When using other backends, it makes sense to work within what that backend can do, hacking things together with meta-data that it doesn't use seems... like a hack.

Re:Bazaar

[mgiuca]

So... should we put the metadata in for every single external client every other random person uses?

No, of course not. I don't expect Git to support Bazaar features. By "metadata" I mean a generic key-value pair mapping per commit, which allows a client to map arbitrary strings onto arbitrary strings. That way, any third-party tool can store any data it wishes. Bazaar, for example, might create a key called "bzr_rev_id" with the value of the Bazaar revision ID for this commit, to make sure that that data is not lost when pushed up to Git.

Subversion, Bazaar, and (I think) Mercurial all allow such arbitrary key/value pairs in commit objects, making it easy to interoperate between them.

Who cares if others using bzr can't see the bzr style merge history with the svn repo at all. I for one don't.

Wow.. again my original post: "what a selfish decision." Of course you don't care about Bazaar users, because you aren't one. Bazaar users, surprisingly, do care about this sort of stuff when they have to interoperate with other systems.

Now let me explain why this is important. It isn't just because I might want to look back at the merge history one day. It breaks things if this data isn't supported. So I said above I want to be able to store Bazaar revision IDs (the immutable commit IDs equivalent to Git hashes that Bazaar uses) in Git commit objects. Here's an example of what can happen if I can't store that:

1. Create a Git repository called G1.
2. Make a Bazaar branch of G1, called B1.
3. Commit something using Bazaar to B1. Bazaar might assign it revision ID "abcd" (for example; it generates a random string).
4. Push that commit up to G1. This commit turn out to have the SHA-1 hash "1d8929a9". Note that G1 doesn't have any knowledge of the revision ID "abcd".
5. Make a Git clone of G1, called G2.
6. Make a Bazaar branch of G2, called B2. Since Bazaar doesn't have access to the metadata of B1, it looks at the commit with hash "1d8929a9" and assigns it a new revision ID "git_1d8929a9".
7. Try to pull from B1 to B2. It won't work, because the branches are diverged: they have two almost-identical commits, except in B1 the commit is called "abcd" and in B2 it is called "git_1d8929a9".

So it is impossible for Bazaar and Git to work together if any complex distributed branching is going to happen. All of this would be fixed if Git had just one simple feature: if Bazaar could store in that commit a key/value pair with the key "bzr_rev_id" and value "abcd", then in step 6, B2 could check that key and create a commit with revision ID "abcd", and thus remain in sync with B1. This is what I meant by metadata and why I think it is selfish that Git doesn't support it.

The only thing I see happening is trying to mash together some superfluous system putting data that will never be used by the majority of cases and is not necessary into the repository.

It is a simple system and a very common idea which is used all over the place for extensibility and interoperability. Look at HTTP or MIME (email), with the ability to add arbitrary headers. Look at files (xattrs) which allow metadata to be tagged on files in a file system. Bazaar, Subversion and Mercurial support it. It is a generally useful feature for a revision control system to support. It has nothing to do with incorporating metadata from other external clients; that is just a nice usage of it.

Re:Bazaar

[walshy007]

Git doesn't store meta-data in svn repositories and yet two git repositories checked out from svn ones can interact just fine.

This all seems to be an artefact of bzr not addressing things by content and hash values like git does. Git's method avoids polluting the dataset of the original while still being interoperable between checked out aspects.

If anything it seems more a design flaw in bzr that should be remedied.

Re:Bazaar

[mgiuca]

As you've noted, that's because Git indexes things by their hash, not an arbitrary name. While it works in Git's favour in this case, that doesn't mean all other VCSes have to be like it. Why is it a "design flaw in bzr" that it doesn't index things by hash? The only advantage of this is that it would interoperate with Git. Now on the one hand, you're telling me "why should Git be changed to support Bazaar" (to which I said: it doesn't have to support Bazaar, it just has to support a single generic feature), and on the other hand, you're telling me "Bazaar should be changed for the sole specific purpose of supporting Git."

Also, you're wrong about git-svn (as far as I can tell). From my reading of this manpage, it does store metadata in the commit log ("git-svn-id"), which it needs in order to rebuild the Git data structure (which is richer than Subversion's, since it can have merges). There is a --no-metadata option but it "can only be used for one-shot imports as git svn will not be able to fetch again without metadata". It sounds as if Git does rely on metadata in the foreign VCS! (In this case, it is crudely shoved in the commit log, which is something that bzr-git does too.)

The fact is that all VCSes have slight (or major) differences in their data, and properly interoperating requires "polluting the dataset of the original". It's just a question of whether the original has metadata (so the additional data can be stored away where nobody has to see it unless they really want to), or if it's necessary to crudely shove that data into the commit log, like git-svn does.

Re:Bazaar

[walshy007]

It sounds as if Git does rely on metadata in the foreign VCS!

The metadata you are talking about is stored in the local git repository that is importing the subversion one, not subversions. It does not affect upstreams repo at all. And again, git repos cloned from svn ones can interact just fine.

I have no issue with people doing whatever they like with metadata on their own local copies, only when it has effects on upsteam does it matter, which the changes to git you are proposing do

why should Git be changed to support Bazaar" (to which I said: it doesn't have to support Bazaar, it just has to support a single generic feature), and on the other hand, you're telling me "Bazaar should be changed for the sole specific purpose of supporting Git."

Not at all, I'm saying, if you want a good way to tell data is the same.. hash it. Certain designs have certain benefits, if you want the benefits git has, well, you have to go with a similar design. Don't want to change it? fine, then just don't get the features it yields either.

My logic is, what matters in a vcs, is the data. Having a uniquely identifiable and replicatable name based off that data is the only sensible thing in a distributed environment. Anyone who doesn't want to is fine, but has to put up with the problems they create by doing it their way.

Re:Bazaar

[Anonymous Coward]

I'm in game development and our repositories have tens of thousands of files plus quite a few large files (hundreds of MiBs to a couple of GiBs) and we mainly use Windows. I don't need to tell you that any DVCS other that Git just chokes under the repos, and even Git doesn't handle the large files that well. Besides, with most of our team being non-programmers, the GUI plays a crucial role. Also, we are indie, so software licensing is a noticeable cost.

Long story short, after some experiments with some DVCSs and even going with Mercurial for a while, we went back to Subversion, which is a pain ("20GiB trunk with more than a few tags/branches" anyone?!) but at least it's stable and straightforward and has a couple of more than usable user interfaces, not to mention a multitude of other tools.

Re:Bazaar

[npsimons]

I would prefer Bazaar over Git for an actual software project.

*shrug*. Git has worked well for me on software projects I've used it for, and obviously the Linux kernel maintainers prefer it. The technical and performance merits of git vs Bazaar vs. Mercurial are debatable. I personally don't have enough time or mental capacity to properly master a plethora of tools that are either redundant or may soon be obsoleted (this is why I object to learning proprietary tools, like MS or Apple products). Bazaar and Mercurial do have the advantage of being open source, but git has inertia in my headspace, and it's not going anywhere anytime soon. However, competition is a good thing, and to each their own.

Re:Bazaar

[dmpot]

I have never heard this argument before

A question about explicit rename was raised so many times on the Git ML, and Linus and then many other developers answered it extensively, so I suggest you look-up their explnations.

the old mantra "explicit is better than implicit" applies here

A mantra is not a logical argument, and while it may be true for many cases, it tends to be oversimplification of reality.

When you say, explicit is better than implicit, does it mean than the C language is better than Python, because allocation memory in C is _explicit_? And then following this line of reasoning, one may conclude than the Assembler language is even better than C, because register allocation is explicit.

The principle explicit is better than implicit only applies to things that matters, while those that do not matter are better to be implicit, so they won't be distraction.

Now, if we speak about renames, what it matters is the end state and how source code was moved, so file content is far more important than some abstract file-id. In other words, it does not matter whether you rename some file or moved most content to a new file. If you are not convinced, then take a look how the "diff" command works. It does not show how lines were actually, moved, but it shows the difference between two states. And, yes, "diff" uses some heuristics to detect this difference, so it does not always produce the perfect result.

The following is all that is required to trigger a complete merge failure on Git

So what? It seems you believe that if something merged automatically then it is good otherwise it is not.

In practice, failure of automatic merge can be a _good_ thing, because it can make a developer to think and resolve the conflict correctly. Definitely, we do not want to bother developers with trivial failures, but when a file is mostly re-written and then it is renamed, then there are some reasons for it. So, a good VCS should be to make obvious the cause of the conflict, and provide means to resolve it easily.

Based on my experience, in practice, the situation that you describe will lead to the wrong merge result anyway. I mean even with less extensive changes to one file when the merge detected automatically and there was a trivial change on the other branch, the end result was more often wrong than right. Of course, if you rename files without any good reason, then you may have more often situations where the automatic merge will be more often right, but I always rename for _some_ reason. So, significant re-write of some file and then its rename did not happen for no reason, and in most cases, no automatic merge can handle that merge correctly. And in trivial cases, it is not a problem to resolve conflict manually.

The merge problem is not new, it is extensively studied in CS. There are some very "smart" algorithms that reduce the number of automatic merge failures. Unfortunately, except some specialized cases, all of them increased the number of correct merges insignificantly and only in trivial cases, which any developer with proper tools will handle without any problem, but the downside is the increase of wrong merge results in far more complex cases. So, this trade-off is simple wrong, and "stupid" 3-way is usually the best approach for general case.

If you are interested in the subject, you should read the discussion that took place between Bram Cohen and Linus Torvalds, which took in May 2005. (Probably, rename also discussed there or maybe it was another thread around that time.)

It is a fully distributed version control system (you might say with Subversion-like centralised support tacked on as an optional feature).

I have never claimed that Bazaar is not truly distributed, but it feels to me like a DVCS that is optimized for a centralized workflow. You certainly can use in other ways too, but it is not so s

Re:Bazaar

[mgiuca]

When I said "I have never heard this argument before," I meant I have never heard anybody say that "explicit renames are for novices, experts prefer automatic rename detection." Believe me, I have had long, long arguments before about explicit vs automatic renames. I have argued for a long time, done experiments, collected data on both real and trivial repositories, and I have convinced hardcore Git fans that explicit is the way to go. At one point, I spent three hours converting one of my major team projects (which had carefully-annotated renames in Bazaar) to Git and then going through the entire history by hand to see which renames Git detected and which ones it didn't, and it failed a staggeringly high proportion of the time.

Maybe we weren't "doing it right" (i.e., maybe we renamed too often or we changed the files too much). But this is precisely the point: since we used Bazaar, we didn't care. We had the freedom to rename or change the files as much as we wanted, and we did so. If your argument is "you should have been using revision control more responsibly" then I would argue that the tool is controlling you and not the other way around. I don't want my tool to fail just because I am not following best practices.

So what? It seems you believe that if something merged automatically then it is good otherwise it is not.

Not at all. Merge conflicts are good. They point out the pieces of the file that need attention, so I can manually fix it up. The point of this experiment that I proposed was that if you do it in Bazaar, you get a merge conflict if necessary (that is, the pieces of the file that merge without conflict just merge, but the pieces of the file that changed in both branches get a >>>> <<<< conflict marker). Whereas in Git, you don't get any meaningful conflict -- you just end up with two completely separate files and you are on your own to a) figure out that they are in fact the same file, just with a different name, and b) do the merge yourself, including detecting and resolving any conflicts.

So, significant re-write of some file and then its rename did not happen for no reason, and in most cases, no automatic merge can handle that merge correctly.

Again, I am not saying the automatic merge should handle it. But if I did make significant changes to a file, and renamed it, who are you (or Git) to tell me that it is now a different file? Semantically, as the author of the file, I know it is still the same file, and it still makes sense to attempt to merge them (and identify any conflicts). This is what I am talking about. Say I have a file A with contents:

def foo():
xxx
print 1
yyy

def bar():
aaa
bbb

In the branch, I rename the file to B and also totally change the function bar:

def foo():
xxx
print 1
yyy

def zonk():
ppp
qqq

In the master, I make a slight change to foo:

def foo():
xxx
print 2
yyy

def bar():
aaa
bbb

Now run this experiment with Git, and you will find that Git spits out two files (when you try to merge): a file called "A" with the same contents the file had in master, and a file called "B" with the same contents the file had in the branch. Now it is up to you to realise that they are still the same file. You have to manually rename A to B, and then manually figure out that bar should have been replaced with "zonk" and foo should change its print from 1 to 2. Git does not even try to help you here, because it thinks of them as two

Re:Bazaar

[dmpot]

I have argued for a long time, done experiments, collected data on both real and trivial repositories, and I have convinced hardcore Git fans that explicit is the way to go.

I don't know anything about your experiments, but it would be interesting to see that on real-life repositories, such as the Linux kernel or Git itself. I doubt that it will work any better than what Git does based on heuristic, but it would be interesting to see.

As to your artificial example, it is not convincing, because it is not what you normally have during development, and the conflict is easy to resolve anyway.

We had the freedom to rename or change the files as much as we wanted, and we did so.

Let's suppose, I move a few functions to another file. Now how is your explicit rename/copy tracking is going to help here?

In my experience, moving code around refactoring is much more common than renaming or copying files. With Git, it is easy to find where some function came from. Somehow I have not found similar functionality in Bazaar, but maybe I did not try hard enough to find it.

I don't want my tool to fail just because I am not following best practices.

Git does not fail, it is just that it works better in some cases than in others. Best practices describe how to take most advantage of it. It does not mean that you cannot do in other ways.

but the pieces of the file that changed in both branches get a >>> <<<< conflict marker).

In simple cases, those markers are really useful, but relying on them in complex merges leads to mistakes, because they do not mark all places that has to be changed (regardless whether rename/copy is involved or not). So, much better way to handle complex merges is to use "gitk --merge", where you can see what was changed and why.

Now, for trivial changes, rename heuristic in Git works pretty well. In cases, where you have substantial changes to some files (=>50%), I primary rely on "gitk --merge" anyway, so those markers are not so important. Not to mentioned that in many cases, those markers can be around the wrong lines.

Personally, I don't have much experience with explicit rename tracking (except SVN but it does not do branches well, so it does not count), but accordingly to Linus, explicit rename in BitKeeper caused more confusion than being helpful.

It is entirely possible to apply the same workflow in both tools.

I have not said that is impossible, but it may not be as easy. And this is the reason why people tend to use one tool in one way, and the other in another.

If we speak about Bazaar, a typical approach is to create a feature branch, to do your work on it. When everything is fine and tested to merge it to "trunk". The problem is that intermediate steps may contain mistakes.

One of key features of Git is interactive rebase. It means that you can amend any commit later. You may want to do that due to some mistakes that you did not notice initially, or based on feedback from other developers, or result of testing the same code on another platform. In my experience, it is rare that the initial series of patches is perfect, especially if we speak about not very experience developers or those who work on the code that they do not know well.

Sure, you can use some patch management system instead, but if it is not integrated with your VCS, it is a real pain. But even if it is integrated, it is more complex than you really want in most cases. Obviously, if you maintain some patches on the top of another code, then you need a patch management system. But if you only want to be able to correct your initial series of patches, interactive rebase is much easier to use.

that you can commit part of a changeset without having tested that it compiles

You can always do that with any VCS. The index just gi

Re:Bazaar

[mgiuca]

I don't know anything about your experiments, but it would be interesting to see that on real-life repositories, such as the Linux kernel or Git itself. I doubt that it will work any better than what Git does based on heuristic, but it would be interesting to see.

You doubt what will work any better than Git's heuristic? I'm talking about Git's heuristic. By definition, explicit renames will work 100% of the time (if you do it correctly, which is exceedingly easy to do). They work when you do it right, they fail when you do it wrong. Git renames work less than 100% of the time. (How much varies according to what you're trying to do, but it's provably less than 100% of the time because it's failed on me when I expected it to work.) I prefer tools that fail only when I screw up, as opposed to tools that can fail even if I do the best I can do.

As to your artificial example, it is not convincing, because it is not what you normally have during development, and the conflict is easy to resolve anyway.

My artificial example is a simplified version of something I've done all the time. Why is it not what you normally have during development. Isn't it extremely common to modify a file in both the branch and master before the merge? If so, all I have to do to trigger this is also rename the file, which can't be that rare.

Of course in my simple example the conflict is easy to resolve. But you must see that this same thing could happen on a very large file, and it would be very hard to resolve, because Git hasn't actually done a merge (it's just saying "there's a conflict between an edit and a delete, oh and by the way there is a new file as well.") That means you need to manually compare two files (the one from master, and the one from the branch) and merge them -- you may as well be using Subversion to merge branches because it will give you just as much help.

Let's suppose, I move a few functions to another file. Now how is your explicit rename/copy tracking is going to help here?

In my experience, moving code around refactoring is much more common than renaming or copying files. With Git, it is easy to find where some function came from. Somehow I have not found similar functionality in Bazaar, but maybe I did not try hard enough to find it.

I agree that moving code from one file to another is more common. Bazaar can't track that (it just shows the function deleted in one file and added in the other). But can Git actually track that? I've never seen it. I just did an experiment now -- I made a file with three reasonably-sized functions, committed it, then moved one function to another file, and committed those changes. Git didn't do anything different to Subversion or Bazaar -- it just shows many lines deleted from file A and many lines added to file B. If there is a way to get Git to properly track that function, let me know... it doesn't seem obvious.

One of key features of Git is interactive rebase.

Oh I see -- when you said Git branches are often more stable than Bazaar you mean because of this culture of editing your branches so they make sense. Fair enough -- Git does have more of a culture of that and better tools for editing history (Bazaar has "uncommit" which lets you go back as many commits as you like and redo them, but certainly not the powerful history editing capabilities of Git).

But I really don't see the point in these tools. The point of a VCS is to track the history of development. No project is going to be perfect all along. If there was a bug introduced in revision 3 and fixed in revision 6, I don't see the point of going back and editing revision 3 to pretend that bug never happened. If you're going to lie about history, you may as well not be tracking it. It's better to say "hey, we put in a bug in revision 3, I'm fixing it from here onwards."

I sort of understand the idea that if you want to submit code to a project you don't control, you would like those people you are submitting to to be able to look at your history and believe that you were perfect. But is that really helpful from a software development perspective, or just an ego thing?

Re:Bazaar

[dmpot]

By definition, explicit renames will work 100% of the time

No merge algorithm works correctly all time, and any merge relies on certain heuristics to find where to make changes inside of files. Just tracking some abstract file-ids does not mean that the merge will find the right place or even the right file for those changes. It is much better to look at the _context_ to find the correct place when changes are applied.

That means you need to manually compare two files

If you do that it only shows that you do not know how to use Git. There is a much better way to merge than that.

But can Git actually track that?

As with file rename, Git does not track those things, but it can easily _find_ them. Git log's pickaxe allows easy to find where some function (or just some line) were introduced.

The point of a VCS is to track the history of development.

but the question is what history is worth saving. Should every version of each file to be saved in history every time when you hit "Save" in your editor? Or maybe even each your move during editing those files? Obviously, those intermediate steps are not interesting!

So, the question is what is the right moment when you say that it worths saving in history. In Bazaar (and many other VCS), it is the time when a new commit is created, which means that you cannot commit your changes unless you have passed all reviews, or you end up with a _lot_ intermediate changes that just pollute history and make it difficult to understand bisect later. Storying your patches outside of your VCS and sharing them by other means than the normal "fetch" is additional burden to all developers, and it may cause mistakes and confusion.

Git gives you freedom to choose when you want to make your history immutable. Typically, a patch series becomes immutable when it is merged to the 'next' branch. But as long as your patches are going through reviews, you can modify your patches based on feedback that you received.

So the goal is _not_ to make the history perfect, but to avoid the development history being fill with crap, which obliterates actual changes through a lot of small errors in commits and fix-ups to them. Also, many developers do not write good commit messages initially, because they consider somethings as self-obvious at the moment when they look at the problem. However, when someone else is going through those changes a few years later, it makes difficult to understand what are motivations behind of those changes or why it was implemented in this way and not some other. Then you may want to add additional information to those commits, like who have reviewed and tested those changes.

Now if you do not really care about history, like you never go back to study what was changed and why then those fix-ups and other crappy commits are not going to hurt you much. But if you try to bisect more than a year worth history of some active project to find the cause of some tricky bug, you will see that having cleaner history makes huge difference.

Re:Bazaar

[schamarty]

Branches as separate file system directories really do suck when you're switching between quite a few. Just because you like it doesn't mean it's the right idea.

And any VCS that touts explicit move/rename as a *positive* will never be able to track bits of code across refactor boundaries (think of a critical 100-line function moving from foo.c to bar.c 3 months ago. Now tell me how a new project dev would find the history of that chunk of code before the refactor).

Names and such

[girlintraining]

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

[PCM2]

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

[nschubach]

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

Re:Names and such

[girlintraining]

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

[definate]

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

[Anonymous Coward]

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).

Re:Names and such

[EvanED]

...lately as a sole developer, I never saw any significant difference between CVS and Subversion despite how lauded Subversion was.

Oh man... to each his own. :-)

My own experience is that I learned version control with Subversion, and after I was somewhat familiar and mostly happy with it, had to work on a couple projects for some time that was using CVS.

And man... dealing with CVS was almost universally about as much fun as pounding nails into my eyes. Or so I suspect, I haven't actually tried it. To try to quantify it less facetiously, I would honestly pay $100 for some sort of "you will never have to use CVS again" insurance.

Re:Names and such

[Anonymous Coward]

In the case of Eclipse I guess that the open source hillbilly that came up with the name was IBM, and I'm not sure it would look out of place on one of their proprietary offerings. I'm sure you'd have a good laugh at "AIX" (Aches?) or Unix (Ha ha, play off the name Multics, must have been killing themselves with laughter).

Is "Ruby" particularly weirder or hillbillier than "Java"? I guess I just don't see it.

Re:Names and such

[kikito]

What is a car?

Re:Names and such

[Anonymous Coward]

While "git" and "subversion" certainly wouldn't be seen as flattering names by outsiders, I can't see how you could complain about Eclipse or Ruby. Highly paid marketing types have named a popular car model "Eclipse," for example, and naming something after a gemstone seems perfectly reasonable.

Re:Names and such

[toddestan]

The Mitsubisihi Eclipse dates back from the late 80's....

Re:Names and such

[mcvos]

I definitely prefer the vibe of the open source project names.

I already have my name ready if I ever invent a language: Tawny. Would be cool if it was some sort of port and somehow related to Ruby, but I have no idea how to accomplish that.

Git is the shit

[Anonymous Coward]

'nuff said

because the others still suck

[quantaman]

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

[euroq]

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

[EvanED]

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

[siride]

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.

Re:because the others still suck

[Anonymous Coward]

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).

This is not unavoidable by any means, it is just what filesystem choice you made.

Re:because the others still suck

[bigpresh]

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).

I think the point being made was that, in Subversion, you can check out just a small part of the repository if you want to do so, rather than the whole thing. I'm not aware of that possibility in Git.

Re:because the others still suck

[mfwitten]

You can also use git's `checkout' to grab files from other revisions, and it updates the index at the same time.

Re:because the others still suck

[foniksonik]

Wierd. I've got 10 people working with SVN and the only time it's been disturbed is when we had a contractor come in and try to use Dreamweaver to manage his checkouts. Disaster over and over.

With SVN use Eclipse if you don't know any better. As long as you don't mess with the filesystem directly it will just work. CLI is fine of course and Cornerstone 2 on Mac is like a gentle breeze soothing away all your problems. TortoiseSVN is asking for trouble (Windows).

YMMV.

Re:because the others still suck

[piquadratCH]

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).

Another example is Django. A Subversion checkout (only trunk, no branches or tags) uses 186 MByte on hard drive, a Git clone uses 87 MByte. That's really astonishing when considering that the git clone contains 6 years of history and 10600 commits.

Re:because the others still suck

[Anonymous Coward]

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

...as opposed to svn's "store an uncompressed duplicate of the last checkout in your local project" design - which (on several projects I work on) is considerably larger than the locally stored git (or Mercurial) repo?

Lack of tooling

[Luthair]

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.

Re:Lack of tooling

[bgat]

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

[lennier1]

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

[MemoryDragon]

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

[euroq]

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.

Re:Lack of tooling

[Ice Tiger]

This is probably the only reason we're not seriously considering Git and use SVN instead, SVN works with anything nowadays.

Re:Lack of tooling

[Anonymous Coward]

Anyone care to compare against AccuRev?

My company is migrating to it and so far it feels like junk compared to git or even svn. No way to delete anything, streams instead of branches, no tagging, a large role based permission system...... someone more versed in RCS than I care to rip it to shreds? I've been waiting to hear a good argument against it.

Re:Lack of tooling

[Anonymous Coward]

We've solved the workflow problems in our org with a few simple tools that standardize the steps a developer goes through when making a change. The first script confirms the ticket #, fetches master, and sets up a clean feature branch named to correspond to the ticket #. When the developer has committed their changes locally, they run another script that records metadata about their change and submits it to an api that stores the association (branch name to ticket #) and publishes the branch to a centralized location. Later on, application owners merge the feature branches they want to include, and we have tools that can determine what tickets were included by looking up the relationship between the branch name, commit ids, and ticket numbers.

Granted, this is specific to our environment, architecture, and workflow needs, but it was not a huge effort to set up, and allows to enforce some amount of best practices that were impossible to do with CVS.

Once developers got a hang of git and the above set of tools, their productivity skyrocketed and their understanding of the build & release process increased greatly. They would never go back to git, and the only people asking about Subversion have pointy hairstyles.

Re:Lack of tooling

[Andrew Cady]

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.

Unix interfaces are designed for completeness, not learning curve. The model of learning is that you learn a whole little language, and then you use it. You may say that that just "sucks," but show me a Turing-complete point-and-click learn-as-you-go interface and we'll see which is easier to use.

TL;DR: GUIs are easier to use because they do less.

Tower, GitHub, GitX client (Some Mac only)

[SuperKendall]

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)

[syzler]

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

A number of large external factors in adoption

[SuperKendall]

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.

I don't Git it....

[man_of_mr_e]

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....

[Anonymous Coward]

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....

[spitzak]

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....

[siride]

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....

[dwarfsoft]

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....

[siride]

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

Re:I don't Git it....

[EvanED]

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....

[Chibi Merrow]

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....

[MemoryDragon]

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....

[MemoryDragon]

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....

[ls671]

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.

Re:I don't Git it....

[EvanED]

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....

[MemoryDragon]

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....

[EvanED]

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....

[dwarfsoft]

I was using it as a document repository. As such there were files that took on the titles of documents. It worked fine for the 5 years I was using Subversion on Linux and Windows. It worked fine while I was on Linux using Git (connecting back to the subversion repo). In order to make the change now I need to remove all existing files that are experiencing the problem and resubmit in the new location.... or I can just keep using Subversion without issue.

I certainly haven't named any new files with Unicode Characters (really its just 1 Unicode character, e acute), but the issue is there now, and if I ever need to revert to older documents/folders. I do use Git for a couple of new Repos, but not as extensively as I use subversion.

Re:I don't Git it....

[man_of_mr_e]

I wasn't talking about the command line. The command line is probably roughly equal, annoying wise that is..

I'm talking abou the GUI tools that are currently available. They suck, and doing tasks like cherry picking files is a pain in the but. Of course, the fact that there's a term called "Cherry Pick Commit" that has nothing to do with "Cherry picking" files for commit.. might be part of the reason... You are right, though.. not having to checkin all files in one command is nice.

My beefs with GIT include some of yours. The huge amount of time to download. With SVN, you just download the latest.. but with Git, you have to download the entire change tree locally. Also, i find the git terminology to be (what seems to me) deliberately obscure. Terminology that has been in use for decades is changed for no apparent reason, other than to say "Hey, we're different". This leads to making mistakes when you confuse similar terminology between systems that do different things.

My other major beef is that, while it's nice to be able to do version control disconnected, I dislike having my check ins local.. version control is also a "save my ass", and if my laptop takes a trip down a flight of stairs, anything that's not pushed is lost as well.

Re:I don't Git it....

[EvanED]

I'm talking abou the GUI tools that are currently available. They suck, and doing tasks like cherry picking files is a pain in the but. Of course, the fact that there's a term called "Cherry Pick Commit" that has nothing to do with "Cherry picking" files for commit.. might be part of the reason... You are right, though.. not having to checkin all files in one command is nice.

So I can't speak to GUI tools on anything but Windows, but there's a TortoiseGit that functions nearly identically to TortiseSVN. It even (at least mostly) hides the index from you.

My other major beef is that, while it's nice to be able to do version control disconnected, I dislike having my check ins local.. version control is also a "save my ass", and if my laptop takes a trip down a flight of stairs, anything that's not pushed is lost as well.

That sort of gets back to the "it's easy to forget to push" problem. If you're not subject to this problem, then I disagree that there's much of a difference: if I lose work because I deliberately didn't push, that's because I don't have repository access, and then I'd have "lost" that work under Subversion anyway because I wouldn't have done it in the first place.

As for remembering to push, there is a problem there. Tortoise is nice because on the "yes, you've committed" dialog there's a nice "push" button staring you in the face, so it's pretty easy to remember there, especially if you get in the habit of pushing after every commit.

For the command line, I haven't found a perfect solution... I think I want to write a shell alias that will run git as normal, but if I said "git commit" will print out "don't forget to push!" when it's done. I haven't gotten to that yet.

And one of the two biggest repository tangles I've had to unravel had at its root the fact that I forgot to push from one copy of a repository, developed in another, and then tried to sync everything up. That took some time to even figure out what happened, and rather longer to figure out the best way to fix it.

That said, I've also had a time when I've left dirty copies of files sitting around in a Subversion working copy for months without noticing, and that caused a problem too.

TLDR I do think that this is a drawback of Git, but for me it's so drastically outweight by being able to work disconnected that it almost doesn't register.

Re:I don't Git it....

[euroq]

Then you're doing it wrong. You don't commit half of the files you want to push... you only commit the files you want to push, and then if you want to commit the others but not push them then you commit those separately, and only push the commit that you wanted to get to other repositories.

However, I do admit that it seems that Git is harder to use than SVN, from my experience with working with a team of about 10 developers who were new to Git but not SVN: they have failed at doing what shouldn't be hard. I've been called upon literally over a dozen times to help developers when they can't figure out how to do what they need to do with Git, and especially how they have to fix a mistake that they've made.

I wonder if it is because Git is inherently harder to use (the command line interface certainly sucks vs. a GUI), or if it is just a problem with people trying to incorrectly use Git in the the way that CVS/SVN works.

Re:I don't Git it....

[euroq]

(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.

I HATED this shit with SVN, I wanted to check out the entire repository but it was just too big, so I could only check out parts of it. Now, with Git, I've changed to where I love the fact that I have everything on my local storage.

What I think is that the reason repositories were so big in the first place was because CVS/SVN encouraged it. With Git, if a repository is too big and you want to split it up, then the repository shouldn't have been so big in the first place! If bet that if there were never a previous incarnation of VCS before Git, then people wouldn't throw their entire company's portfolio into one big friggin' repository. For example, if you have modules that work together, and it makes sense for these various modules to be released in separate versions (i.e. 1.5 of feature1 and 1.6 of feature2), then you should have separate repositories in Git. And that's even if the build system requires both repositories... OK then, have it get both repositories!

(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.

I don't think this is a Git vs other VCS problem... it's just a general problem. If you never dealt with any other VCS then you wouldn't have mentioned these points. With forgetting to push, I think it's better to forget to push than to accidentally push something you didn't want to, IMO.

Re:I don't Git it....

[Antity-H]

I was all for a git migration at work, if only for perf reasons. With the new 1.7 features I am not so sure anymore.
I still love git, but I also think it is not a tool for everyone. Getting your head around distributed can be difficult for some people and implementing git in large corporate environment can require subtlety too.

Anyway have a look at the 1.7 changes http://subversion.apache.org/docs/release-notes/1.7.html

Re:I don't Git it....

[man_of_mr_e]

Let me give you a little example. I recently worked on a project that was written in Visual Studio 2008. On my development machine I have Visual Studio 2010. For 99.999% of things, I can develop in VS 2010 and commit the source changes no problem. However, loading the project in VS 2010 converts the project to the 2010 format.

So, I want to check in (and push) the source file changes, but not the solution and project file changes. And i don't simply want to ignore the solution and project files, i just don't want to *push* them. I still want them versioned locally. This sort of thing sucks.

You also can't just get one file from a git repository like you can from svn.

Re:I don't Git it....

[man_of_mr_e]

I haven't been able to get TortoiseGit to work. It's been a while, about 6 months.. but I had problem after problem (don't remember what they were anymore) and finally gave up on it. The only gui that worked for me was git extensions... Maybe things have improved with tg.

Regarding the "forget to push", that's not quite what i mean. I mean, I like to checkin things to a branch regularly, whether it's broken or not. When i'm finally ready, i merge my changes with the root as a single changeset. That's not something you want to push to your primary repository. You could setup a remote repository just for your working area, but that's just a pain and a waste of space.

The whole workflow is just different.

Re:I don't Git it....

[euroq]

So, I want to check in (and push) the source file changes, but not the solution and project file changes. And i don't simply want to ignore the solution and project files, i just don't want to *push* them. I still want them versioned locally. This sort of thing sucks.

I do understand your example... but I still maintain that you're just doing it wrong. You don't need to commit them at the same time. Just commit them separately. In another VCS, you would check them in separately if you wanted to do what you're talking about.

There's no getting around the fact that you need one command to check in or commit one set of files, and another command to do the same to the second set of files, in any VCS.

You also can't just get one file from a git repository like you can from svn.

This may be true... but I've never encountered such an example in my life. The only times I've gotten a single file was by browsing online repositories, and certainly never in a case where I actually wanted to check a file back in. But in any case, that's certainly an example of what SVN can do that Git can't.

Re:I don't Git it....

[Anonymous Coward]

SVN easier?

I wanted a version control system for years. Tried to set up CVS. Too complicated. Tried SVN. Too complicated - and apparently it requires running Apache, which it's thousands of configuration options, each of which have to be understood how it affects security. Besides, I'm already running Nginx, so why would I want Apache?

Then I read about Git. Downloaded it and installed it. Used it. Notice anything? No setup step. Just create a repository (git init), and *maybe* change your email address in .git/config. If you don't need to use your official email address, it doesn't matter. The default "$USER@$HOSTNAME" works fine for internal use.

I have yet to see any version control system as easy to get started with as Git.

Re:I don't Git it....

[man_of_mr_e]

SVN can use apache, but it doesn't require it. There is an svn server that runs without apache.

Yes, you're right. SVN does require a bit more up front work, but this is done by one person. the SVN clients work a lot more smoothly for the end user.

Re:I don't Git it....

[Anonymous Coward]

Gits nasty side is its quirky command line

AMEN. Linus doesn't know how to make a proper user interface. The command line of Git SUCKS.

Re:I don't Git it....

[andsens]

Yep, except when you're on windows. That would be the escape character in the commandline.
Friggin idiot who invented that stupid windows cli.
"Hmmm, yes, let's not use POSIX! How about we invent our own standard and make it really crappy, and let's only follow it half of the time!"

Re:I don't Git it....

[Daniel Phillips]

Git has some nice advantages, especially in distributed environments.. but I still prefer svn because it's just a lot easier to use.

That is true, however SVN is painful and limited. Don't even think about developing on a branch. (Works fine until its time to merge.) Mercurial on the other hand is just as easy to use as SVN and supports the same distributed, object based model as Git.

Re:I don't Git it....

[Daniel Phillips]

As stupid as it sounds, I don't like any of the workflows for setting up an initial repository.

Oh I know what you mean:

git init && git add . && git commit -a

It's even harder in Mercurial:

hg init && hg add . && hg commit

Re:I don't Git it....

[beelsebob]

Then it's simply an error in misunderstanding how git works... git push is nothing comparable to svn commit, it simply copies stuff from one repo to another repo. git commit is comparable to svn commit, and is more than capable of only submitting a subset of changes to be committed.

Re:I don't Git it....

[beelsebob]

As a native english speaker, I must say –don't give software authors an excuse to fuck up with their unicode support. It's not hard to get right, and it's something that every single piece of software should be able to get right.

Re:I don't Git it....

[mcvos]

You can always cherry pick the commits you want from a different branch. Git is way more flexible here than SVN.

Re:I don't Git it....

[mfwitten]

what if you only want to push/commit parts of the change you made in a given file then ?

You shouldn't conflate committing and pushing.

For committing parts of the change you made in a given file, use `git add -p' to sift through the diff hunks and even edit hunks; `git stash' can also be useful here.

Re:I don't Git it....

[mcvos]

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

How is this a problem with git? I find SVN frustrating because I have to commit all changes in a file, whereas git allows me to commit only the changes that I want to commit. For example, I may have fixed several bugs in one go. The right thing to do would be to put them in separate commits, but SVN makes that really hard to do. In git it's trivial.

Re:I don't Git it....

[mfwitten]

Actually, unicode support IS hard to get right.

Re:I don't Git it....

[shutdown -p now]

Friggin idiot who invented that stupid windows cli.
"Hmmm, yes, let's not use POSIX! How about we invent our own standard and make it really crappy, and let's only follow it half of the time!"

Backslash was taken up as directory separator long before Windows - it dates back all the way to DOS 2.0, when that thing has first got directories. And you can largely thank IBM for that.

Re:I don't Git it....

[mfwitten]

The difficulty here is that your parent is trying to maintain 2 histories locally at the same time, which is of course a PITA because git was designed for such a nonsensical usage case. The solution is to automate handling the second history.

For instance, one could just create the 2008 version of the history by rewriting the 2010 history before pushing, which could be achieved with git's `filter-branch' command.

Alternatively, one could implement commit hooks or other scripts that simultaneously create commit objects and manage a second branch by hand using the low-level plumbing tools to actually commit the `solution' and `project' files from some particular revision with the 2008 files (perhaps a commit tagged `v2008' or something). Of course, one has to keep in mind that these will in fact be 2 separate histories, so merge conflicts might crop up between the `solution' and `project' files over time.

Re:I don't Git it....

[TheRaven64]

It's flexible in the way that Windows NT ACLs are more flexible than UNIX file permissions: doing complex things is possible, but doing simple things is much harder. Git always seems to require long command strings to do simple things and breaks horribly if you get them wrong ('oh, you forgot --rebase? Well, now your local clone is fucked, do a clean pull and manually merge your changes').

It also has the big disadvantage that it makes maintaining branches easy. In most projects, branches should be short-lived entities, where you create it, do some world-breaking work, and then merge back into trunk. Git makes it easier to keep your changes private than to share them, which is not the behaviour that most projects want to encourage.

Re:I don't Git it....

[TheRaven64]

With Git, if a repository is too big and you want to split it up, then the repository shouldn't have been so big in the first place!

So how, if you split a repository into 12 different subrepositories, do you do a commit that is atomic to all of them? For example, if you change an API in one framework and want to update all of the things that use that API atomically? With svn, it's easy - even if you've just checked out a subset of the repository. With git, is it even possible?

Re:I don't Git it....

[TheRaven64]

You only need to use Apache if you want the webdav interface to svn. I use it over SSH, which is trivial to set up. Just create the repository with svnadmin on the machine you want, check it out, and start adding files. On my laptop, I only have the latest version. On my server, I have the complete repository history. On my backup machine, I have compressed weekly snapshots of the repository history. Setting this up took about 10 minutes:

• Install svn packages on client and server. Server was FreeBSD, so pkg_add subversion. Client was OS X, so do pointy-clicky things with a graphical installer.
• On the server: svnadmin create /svn/my_repository_name
• On the client: svn co svn+ssh://server/svn/my_repository_name

Oh, I also made a /svn symlink so I could move the repositories around. On the backup machine, I use svnsync to keep another copy of the repository and use svnadmin dump | bzip2 to dump a copy to a single file for archiving. If you wanted to do incremental backups, that's also easy, but none of my repositories is more than 1GB compressed, so I don't bother.

Re:I don't Git it....

[brantondaveperson]

It also has the big disadvantage that it makes maintaining branches easy. In most projects, branches should be short-lived entities, where you create it, do some world-breaking work, and then merge back into trunk. Git makes it easier to keep your changes private than to share them, which is not the behaviour that most projects want to encourage.

This is the most insightful comment I've seen here. Git encourages exactly the kind of behavior that one doesn't want to see in a well-run development environment. Commit early, commit often, update daily - that's how I like to work - and how I'd prefer others to work too. Git provides easy tools for hero developers to go off and do their own hero work and drop it all in one go onto everyone else. How is this a good thing?

Re:I don't Git it....

[TheRaven64]

How is this a good thing?

It's a good thing for what git was designed for, which was addressing the very specific needs of Linux development. Every Linux distro and every SoC maker ships their own patched version of the Linux kernel. Git was created because Linus wanted it to be easy for them to do this, allowing him to keep the kernel.org tree as his own playground and not have to worry about merging patches that the desktop distros wanted and he didn't.

The mistake that people make is assuming that their requirements are the same as his. In reality, there are very few projects with the same requirements as the Linux kernel. Even most other open source projects are developed in a very different way.

Re:I don't Git it....

[dotgain]

No, working with Theodore Tso is hard to get right.

Re:I don't Git it....

[mcvos]

This is the most insightful comment I've seen here. Git encourages exactly the kind of behavior that one doesn't want to see in a well-run development environment. Commit early, commit often, update daily - that's how I like to work - and how I'd prefer others to work too. Git provides easy tools for hero developers to go off and do their own hero work and drop it all in one go onto everyone else. How is this a good thing?

What? No, in my experience, SVN encourages that much more than git does. Because of its distributed nature, git makes it much easier to share code that's not yet ready for release, while other developers work on the release. Having worked with both, git encourages commit early and often much more than SVN does. It makes it easy for people to work together on code that's not yet finished. In SVN, that's a lot harder. It's SVN branches that I see live on forever, whereas git branches tend to have a very short lifespan, sometimes less than a day, exactly because it is so trivial to merge them again.

Re:I don't Git it....

[xouumalperxe]

Git provides easy tools for hero developers to go off and do their own hero work and drop it all in one go onto everyone else. How is this a good thing?

On the contrary. Git makes it so easy to branch and then merge that branch back that I branch when I feel the need to (which means for most largish feature development), and, since merging the branch back isn't painful at all, I don't delay doing it any more than the actual development work requires. Since it's so cheap to branch off, I can keep partial, non-functioning work committed and pushed without fear of breaking other people's code. How is that promoting bad behaviour?

Re:I don't Git it....

[WNight]

It also has the big disadvantage that it makes maintaining branches easy. In most projects, branches should be short-lived entities, where you create it, do some world-breaking work, and then merge back into trunk.

Haha. No. You've got the git fear. It's somewhat akin to thinking of pointers as unreliable.

Branches are greatly useful and only someone stunted by an inferior VCS could say such crazy things..

Git makes it easier to keep your changes private than to share them, which is not the behaviour that most projects want to encourage.

What projects want to encourage hastily coded features being merged into the main build? Git makes doing whatever you want as easy so you can decide based on circumstances, instead of being stuck with what your tool will do.

Re:I don't Git it....

[Anonymous Coward]

it's something that every single piece of software should be able to get right.

Just as soon as someone invents a magical coloring for strings that tells everything this set of bytes is SJIS or ISO-whatever or UTF-8 or UTF-16.

The only way to fix it is to determine what ought to be the proper local encoding, then have the application store everything its own way and convert on the fly to whatever platform you're on.

Re:I don't Git it....

[EvanED]

I HATED this shit with SVN, I wanted to check out the entire repository but it was just too big, so I could only check out parts of it.

Let me give you a concrete example of where I was screwed by this. I and a version control fiend... I put most stuff that I do that is in some textual format into one, and that includes config files.

The way I set up config files on Linux is I have the .config directory that well-behaved programs use, and those files are just sitting there normally. I also have the actual files of not well-behaved programs (those that make you dump .blah files in ~) under that directory, with symlinks at the location the program expects.

So, I figured I'd put my .config directory into git. Seemed (and still seems) reasonable to me. I like it way better than making a git repo for just .xsession, a git repo for .zshrc and .zshenv, etc. Not only does it seem silly to make a repository for a single file, but that would also allow me to share stuff between, say, .zshrc and .xsession if I ever get around to doing so and have commits be atomic and such.

Until I wanted to check out just my emacs config directory so I could put the contents into .emacs on a machine where I didn't want the rest of my configuration, and Git said "you want to do what? not on my watch."

So now I have a git repo with only .xsession. (Okay, it also has an xmodmap config in it. Still, two files, and no sharing if I decide it's worthwhile to merge .xsession and .zshrc.)

Re:I don't Git it....

[EvanED]

Regarding the "forget to push", that's not quite what i mean. I mean, I like to checkin things to a branch regularly, whether it's broken or not. ... That's not something you want to push to your primary repository.

Wait, so what do you do under Subversion? I'm confused.

Re:I don't Git it....

[EvanED]

*bzzzt* [Though I did figure it out a good workflow when typing up this post!]

I use a bare repository (so I can push to it from home, where I "can't" really pull from), and then a clone of that. You forgot to set that up.

'cause see, here's what I would think would make sense:

mkdir repo
cd repo
git init --bare
cd ..
git clone repo working
cd working
touch foo.txt
git add foo.txt
git commit -m 'Added foo.txt'
git push

but it doesn't work, at least under 1.7.4.1. (Current is 1.7.6 so I'm not that far out-of-date, and upgrading is far from trivial in my environment.)

$ git push
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to '(...)/repo'

However, git push origin master seems to work... I could have sworn I tried that before and it didn't. So maybe my complaint is sort-of-solved.

Still, I firmly believe that my workflow makes sense, and the fact that it doesn't work I see as a blemish on Git. It is that sort of thing that turns people off of software, especially if they're less patient, and especially when there are other good alternatives like Hg. (No clue how I would want to structure things.)

Re:I don't Git it....

[WuphonsReach]

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

I would still love to be able to refer to any item in the repository as some UUID, random generated when the item is first added to the repository.

Then you could reorganize your folder structure in the SVN repo without breaking all of your svn:externals.

So instead of svn:externals pointing at ^/trunk/some/subdirectory, you could just point it at ^UUID:abcdef0123456789.

Re:I don't Git it....

[WuphonsReach]

Yep, except when you're on windows. That would be the escape character in the commandline. Friggin idiot who invented that stupid windows cli. "Hmmm, yes, let's not use POSIX! How about we invent our own standard and make it really crappy, and let's only follow it half of the time!"

Hence the quote:

"Those who don't understand UNIX are condemned to reinvent it, poorly." -- Henry Spencer

Re:I don't Git it....

[WuphonsReach]

I wanted a version control system for years. Tried to set up CVS. Too complicated. Tried SVN. Too complicated - and apparently it requires running Apache, which it's thousands of configuration options, each of which have to be understood how it affects security. Besides, I'm already running Nginx, so why would I want Apache?

You don't need Apache at all.

svn+ssh is a lot easier to setup, especially if you already SSH into the server where you're storing the SVN repository.

Or there's the straight file:// method for times where the SVN repo is on the same file system.

# cd /var/svn
# svnadmin create somerepositoryname
# chgrp -R svngroup somerepositoryname
# chmod -R 770 somerepositoryname
# chmod -R g+s somerepositoryname/db

Make sure the users belong to "svngroup" and they can now get to it with svn+ssh://username@hostname/var/svn/somerepositoryname.

And if you setup your ~/.ssh/config file properly and use specific keys with the command= option for talking to the SVN server you can simplify that URL down to: svn+ssh://hostname/somerepositoryname.

Re:I don't Git it....

[EvanED]

To be honest, very few of those changes sound particularly appealing to me. Really the only three that jump out are:

• The "one .svn directory" is kind of nice, but like I say in another post, there are lots of times where I actually really like the fact that a subdirectory of a working copy is a working copy.
• svn switch checking ancestory is good.
• I don't have enough experience with svn's mergeinfo stuff to know how that stuff works out.

But as far as I can tell, my big issues with Subversion still stand: not being able to work without repository access (of course, you really need a DVCS for that), an absolutely braindead ignore feature (no ability to set "ignore this pattern in any subdirectory"), and the "you're screwed if you update and get bad conflicts" problems. Or support the interactive add feature that I don't use very often with git but when I do is an absolute godsend.

Like I said, I'm sure there are cases where it's not really appropriate.. but I'd really struggle to come up with one where I'd rather use Subversion.

Re:I don't Git it....

[Anonymous Coward]

I wasn't talking about the command line. The command line is probably roughly equal, annoying wise that is..

No, most other VCS' command line interfaces are much more annoying. Probably because they were written by whiny people who need a GUI to hold their hand.

Re:I don't Git it....

[Yunzil]

The right thing to do would be to put them in separate commits

...Huh?

Re:I don't Git it....

[lee1]

Would this do it?: http://www.kernel.org/pub/software/scm/git/docs/git-read-tree.html#_sparse_checkout

Re:I don't Git it....

[EvanED]

No, because the .git directory is in the wrong place relative to the contents. (I needed ~/.emacs/.git, basically; .git couldn't be at the ~ level.)

You could maybe use it if you only ever wanted to pull, because you could do that sparse checkout, move everything up the directory tree, and work with that locally. I'm not sure what happens if you pulled changes, whether Git is smart enough to change the files in their new locations. However, I'm pretty sure you definitely couldn't push back without some directory finagling.

(That sparse checkout is what I did to split up the repository.)

Re:I don't Git it....

[EvanED]

(That sparse checkout is what I did to split up the repository.)

This sentence is wrong and dumb. Ignore it.

Re:I don't Git it....

[mcvos]

Don't mix different fixes/features in a single commit. It's a really simple and useful principle that git makes very easy to adhere to. SVN does not.

Re:I don't Git it....

[Lennie]

I think having a good GUI would help a lot.

Re:I don't Git it....

[euroq]

Well then, I think this is an example of something Git doesn't do well and that's something it wasn't designed for. I suppose you'd have to write a custom script to copy to and from the git repository to the target location.

Re:I don't Git it....

[Yunzil]

Don't mix different fixes/features in a single commit.

Yes. That's what you said. I just want to know why.

Re:I don't Git it....

[mcvos]

This is important because then you can isolate them. You can cherry pick or revert one fix without affecting the other.

This is also why it's a good idea to separate the reformatting of code from functional changes to the code. The smaller, more atomic, more internally related and consistent the commits are, the more power you have over them. For the same reason, a single fix shouldn't be spread out over separate commits. That way you run the risk that someone accepts or reverts only part of the fix, which is likely to break stuff.

Don't underestimate the power of reverting or cherry-picking individual commits. Even in a small team, we used those features of git quite regularly. This is IMO where the true power of git lies.

Re:I don't Git it....

[mcvos]

Git always seems to require long command strings to do simple things and breaks horribly if you get them wrong ('oh, you forgot --rebase? Well, now your local clone is fucked, do a clean pull and manually merge your changes').

I've never had git break anything horribly. Unlike SVN, which is very easy to mess up in my experience. I've also never used --rebase in git. I don't understand the point, so I ignore it, and that seems to work very well for me.

Re:I don't Git it....

[TheRaven64]

If you do git pull without --rebase on a project where other people have made changes, then this seems to mangle your history and make it impossible to push until you somehow demangle it. I've no idea what --rebase does, it's just one of the magic incantations I'm told to use when I work with people who insist on using git, after learning the hard way what happens if you don't --rebase first. Git is supposed to be good at handling merging, but it seems that if you modify a file that someone else modified then its common response is just to sulk and refuse to do anything until you follow some ludicrously complex sequence of steps (in the right order, or you're basically fucked) to manually merge.

Re:I don't Git it....

[mcvos]

Really? I don't recognize any of that from my experience with git. I pulled from other people's repositories all the time, and it automatically merged with my code. Sometimes I did have a conflict, but quite often it could be solved by simply merging in the other direction (pull instead of push, or put one in a branch merge in the other direction, and then merge back). I have done the occasional merge by hand, but not nearly as often as I've had to do that with SVN, which requires manual merging every time two people changed something in the same file. Though the tools for manual merging for SVN were somewhat nicer than those we had for git.

According to my understanding, --rebase was only necessary when you wanted to do something really weird, but I forgot what it was. Or maybe I just didn't understand. I don't think we ever had any need for it.

Large, complex projects require good source contro

[Anonymous Coward]

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)

Mercurial

[thecounterweight]

hg > git > svn

Re:Mercurial

[MemoryDragon]

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.

Re:Mercurial

[Skuto]

In what way is Mercurial better than git?

I use both extensively, but getting the equivalent functionality of git in Mercurial means using several extensions, most of which aren't as good as their git originals.

There are three or four branching extensions for mercurial, and none matches what basic git branches do with the same ease of use. It's as if the developers didn't want to admit that git got it right, and so they stopped short of also making something that works.

I believe git is more popular simply because it's *better*. Mercurial's most touted advantage is that it's easier to learn, but this is a joke. If you develop, you interact with the version control system all day. A tiny advantage in learning it faster is nothing compared to not being able what you want to do afterwards, or having to redo something because the version control works against you instead of with you.

Re:Mercurial

[euroq]

Mercurial's most touted advantage is that it's easier to learn, but this is a joke. If you develop, you interact with the version control system all day. A tiny advantage in learning it faster is nothing compared to not being able what you want to do afterwards, or having to redo something because the version control works against you instead of with you.

I work at a company that has used Git professionally. My team isn't dumb people, but they have fucked up with Git dozens of times. What I quoted is an okay argument at a personal level. However, there is something to be said as an organization that having an easy-to-use tools is better.

I am not making the argument that either Mercurial or Git is better; I am making the argument that tools which are easier to use will lead to less fuck-ups in an organization.

Re:Mercurial

[DrXym]

I am not making the argument that either Mercurial or Git is better; I am making the argument that tools which are easier to use will lead to less fuck-ups in an organization.

I expect with EGit appearing in Eclipse and TortoiseGit putting a reasonable (though still not very refined) UI on top of Windows that the potential for fuckups or knowledge of arcane expressions is largely an issue for advanced users. I expect most devs can get by with what the gui provides.

Re:Mercurial

[Skuto]

I work at a company that has used Git professionally. My team isn't dumb people, but they have fucked up with Git dozens of times. What I quoted is an okay argument at a personal level. However, there is something to be said as an organization that having an easy-to-use tools is better.

Note that I made the argument that git is easier to USE than mercurial, but mercurial is easier to LEARN than git.

I agree with you that tools which are easier to use are to be preferred.

Re:Mercurial

[Anonymous Coward]

I work at a company that has used Git professionally. My team isn't dumb people, but they have fucked up with Git dozens of times.

It has nothing to do with git. The most likely cause is that those people have been previously exposed to other VCS such as Subversion. Un-learning non-distributed concepts when switching to Git is the most major headache.

I've taken people with no previous VCS experience directly to Git and they took to it immediately, with absolutely no problem understanding how it works. The only problem they had was accumulating obsolete branches on their local repos, because Git makes it so cheap. They had to be told to cleanup every once in a while. That's all.

As for Mercurial vs Git, I liked the analogy that said "Mercurial = James Bond, Git = MacGyver". As long as you do things the Mercurial way, everything is silky smooth, it's a lean mean machine. When you don't... tough luck. Whereas Git will let you do things whichever way you want. Personally, I'm partial to a tool that adapts to the way I work, not the other way around. But if Mercurial (or Subversion, or any VCS) works great for you, that's excellent too.

Re:Mercurial

[Anonymous Coward]

Mercurial's really strong side is that it is completely portable and runs natively on Windows boxes. Large corporations *love* this. Making Git run in Windows is frankly a PITA. It is *impossible* to make Git run natively in Windows, but Mercurial does just fine.

Disclaimer: I am an Android, msysgit, and Gerrit Code Review developer for a large corporation that uses these tools.

Re:Mercurial

[MemoryDragon]

Actually not really. HG was written in python which runs basically within an interpreter which also hosts a stack of unix derived libs.
Git currently is running on windows in MSysGit which is native but also drags in a bunch of unix Libraries.
So not too much of a difference here.
Outside of that, a pure Java port of git is in the works, which will be or is utilized by Eclipse.

Re:Mercurial

[Anonymous Coward]

msysgit is a true nightmare to work with if you expect it to work exactly the way git working in linux or another unix-like OS. Read the mailing list and list of bugs for msysgit. Relying upon all of the included tools with msysgit to work is a major flaw; many of the tools do not work correctly with Windows, and are extremely difficult to build in such a way that they do work.

I am extremely familiar with JGit and have forked it for my own purposes in the past. JGit is still not feature-complete in comparison to Git, and major functionality was lacking (such as shallow clones; the clone --depth option) until very recently. Leveraging JGit/Egit in Eclipse can't be done for large projects or in a corporate environment yet.

Mercurial doesn't have any of these problems.

Data, Images, Binary builds etc.

[syousef]

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.

[siride]

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.

[ATMAvatar]

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.

[0123456]

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:Data, Images, Binary builds etc.

[Anonymous Coward]

You are a lazy shit, Use the right tools and partition correctly. Putting everything in one project is stupid and slows down development. God I hate people that put bins and bits and images that should be linked and stored on appropriate storage, not archived in a RCS. Maybe a image control system?
And Yes, Don't confuse a "Revision control system" with a "Configuration control system"
Your're pissing off your co-workers.

Re:Data, Images, Binary builds etc.

[Anonymous Coward]

Argh! That's what checkout scripts should do. Pictures and video are fluid, They change, maybe release to release. The code stays the same (with updates) so it seems that pulling out a bunch of archived pictures (from something that really isn't really built to handle bins or bits, (but it can I guess ) ) seems like TOOL ABUSE.

Re:Data, Images, Binary builds etc.

[syousef]

You are a lazy shit, Use the right tools and partition correctly..

...and you are an anonymous coward. Now please let the grownups speak.

Not everyone get to start at the start of a project or determine the team's tools, build process or repository structure.

Re:Data, Images, Binary builds etc.

[dgatwood]

Pictures and video are fluid, They change, maybe release to release.

Usually less so than the code, actually. If somebody is embedding an image into source code, 99% of the time, it's an icon or some other rarely updated graphic. If somebody is updating an image regularly, odds are they'll have the app pull that image from a web server and cache it somewhere, in which case it wouldn't live in the DVCS (unless your website does).

Re:Data, Images, Binary builds etc.

[Mitchell314]

Learned that the hard way with git. Upon checking out older commits after a computer crash (yeah, macs crash too) since the sub-directories were cleaned: "Uhm, where did my src folder go?"

Why or how I retroactively lost data, I don't know. To be fair, it was probably one of my own build scripts that was to blame.

Re:Data, Images, Binary builds etc.

[DrXym]

I'm not sure how you consider SVN to be any better. Assuming you needed to pull everything you would have a 50GB on your disk plus ANOTHER 50GB for the pristine copy that SVN maintains. And if you work on multiple snapshots, you can add an additional 100GB footprint for each of those.

But most likely you wouldn't be pulling 50GB at a time. If you had a bunch of images / binary junk you should hopefully try to separate them into separate logical modules so you only need to pull the stuff you're working on rather than the entire lump in one go. I don't think this is unreasonable to do regardless of what source control system you use. But yeah because git pulls at the project level you would have to think about this ahead of time to use git with large amounts of data. Also if the data changed very significantly between checkins then git puts a footprint burden onto every clone, not just a central repository.

Re:Data, Images, Binary builds etc.

[DrXym]

I assume you mean VCS. CVS is so fucking useless if can't version control binaries at all. So if you had branch X and branch Y changing the same foo.zip file and you expected each to see its own copy you're in for a nasty surprise.

Re:Data, Images, Binary builds etc.

[gbjbaanb]

and you've just screwed the entire configuration process there.

The whole point of a SCM is that you put your sources in there so you can check it out and get the same set of sources from any point in history. The moment you say "oh that's too big, we'll put it somewhere else" is the day you lose control of that reproducability.

Your images used in the app are part of the source. While there's a place for storing data elsewhere, it still has to be controlled in a way that you can get it back out again for a particular version.

Re:Data, Images, Binary builds etc.

[kikito]

No, you should have an automated script that does all those things for you.

Re:Data, Images, Binary builds etc.

[lgw]

Often it makes sense to store large binaries on a fileserver somewhere (where nothing is ever deleted), and stick references to those in the source tree. The graphics files themselves almost never change, instead you use different graphics files over time.

Re:Data, Images, Binary builds etc.

[Miamicanes]

> God I hate people that put bins and bits and images that should be linked and stored on appropriate storage, not archived in a RCS.

Please keep in mind that pre-Vista, Windows didn't actually *have* proper symlinks. NTFS junctions technically existed since NT4, but Microsoft guarded them like a state secret and bent over backwards to avoid making people aware of them. Also, junctions are more like Ext3 hardlinks, so you can't *quite* use them with reckless consequence-free impunity the way you can with real symlinks.

Re:Data, Images, Binary builds etc.

[hibiki_r]

Your release creation process should be part of your build, and any artifacts and dependencies that you have should come from a dependency repository that the build system can use. Making this kind of thing easy-ish is why people moved to Maven, despite its problems.

Re:Data, Images, Binary builds etc.

[m50d]

Your images used in the app are part of the source. While there's a place for storing data elsewhere, it still has to be controlled in a way that you can get it back out again for a particular version.

Indeed it does. But that storage has a very different set of requirements from a VCS - it makes very little sense to do a diff between two versions of an image file, and even less to talk about branching and merging for them. Use another piece of software for that (heck, use subversion - its limitations don't really apply for this use case). Git does one thing and does it well, which is as it should be.

Re:Data, Images, Binary builds etc.

[WNight]

You want to pollute your source repo with gigabytes of largely irrelevant files? Knock yourself out. Git will do it as well as almost anything else. However, if you want local copies it means either everyone downloading those files redundantly or having a branch that doesn't get copied by default (and thus lose the decentralization).

Re:Data, Images, Binary builds etc.

[kabloom]

You could use rsync to send your releases over the VPN. (And if you're compressing them, you can use gzip --rsyncable first). But if git does what you want, then by all means...

Re:Data, Images, Binary builds etc.

[npsimons]

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

Hmm "data, images, other binaries" - nope, not seeing anything looks like source code to me. Don't know why you'd want to version binary data - line by line diff doesn't work to well on them, and there's always backups. As for executables and other built artifacts, don't you have a one button press way to build them? And tag stable releases? You see where I'm going with this, right? I've personally never seen the point of versioning or backing up autogenerated data; it's like throwing out one of the most obvious methods of compression while ignoring the rule of no duplicated data.

Re:Data, Images, Binary builds etc.

[pclminion]

I see, so you are against the "sync it then built it" sort of working model. You'd rather have more steps in the process. Okay... I guess.

Re:Data, Images, Binary builds etc.

[dgatwood]

and you've just screwed the entire configuration process there.

No, not really. Images that are likely to change are almost invariably not an important part of your app. They're things like the marketing messages you see when you launch a game, the artist of the week blurb you see when you open iTunes and click the store tab, etc.

Images that are actually fundamental to the working of your app almost never change more than two, maybe three times over the entire lifetime of an app, statistically speaking. You add new ones sometimes, but the old images seldom change except when you're doing a major UI redesign; if you're doing major redesigns frequently, that probably says a lot about the quality of the app in question, or more precisely, the lack thereof.

The only real exception to this would be skin collections. In that case, each skin should be in its own repository, and again, each of those individual repositories is unlikely to have very many graphic file changes once the theme is finished. In your main repository, you need only maintain a list of themes and revisions of those themes for each release so you can reproduce a release precisely. Anything beyond that is superfluous.

Re:Data, Images, Binary builds etc.

[turbidostato]

"Hmm "data, images, other binaries" - nope, not seeing anything looks like source code to me."

Source is anything you need to start with in order to produce your deliverables.

For some people is just a bunch of text files. For other people is a bunch of text files plus a bunch of images. And, then, for another people is a bunch of text files plus a bunch of images plus a bunch of binary blobs. It all depends on your requirements*1.

"Don't know why you'd want to version binary data"

In order to be able to re-produce past releases, of course. I.e.: my product depends of my source code, some embedded images from my art department and some third party libraries I recieve as binary blobs.

Of course I could reinvent the wheel and produce my own in-house history control system but then, why would I *want* to do that unless -as it is the case, because of the inability of the SCM tool? Time and again people has been bitten by the "binaries within the SCM" problem but it has always been because the inability of the tool, not because having binaries as part of the sources didn't make sense.

"line by line diff doesn't work to well on them"

That's not the be-it-all of diffing. I may want to produce foo 1.2.3 to diff its *behaviour* against foo 4.5.6 to see when a bug was introduced. If my operational definition for "foo 1.2.3" includes something on the lines of "and the version of library bar that was used back then", so be it.

"and there's always backups"

Repeat with me: a backup, is a backup, is a backup and it is by no means a historical storage solution. A backup is (part of) the tool you use to recover your system to as near as possible a state after a failure. It has absolutly *nothing* to do with helping to your product delivery process and expecting it is as big a mistake as, say, thinking that RAID is a substitute for backups.

"I've personally never seen the point of versioning or backing up autogenerated data"

1) There can be other binaries apart from your own autogenerated data.
2) If there's the chance you won't be able to produce again in the future the same autogenerated data, then whatever you need to do it you should treat as source too (i.e., if foo 1.2.3 must be compiled with gcc 2.95.17, then you need to store gcc 2.95.17, tie it to the corresponding version of your sources and track the evolution of such correspondencies along time, be it within the SCM or not -of course, much the better if you can do it within a one single tool).

*1 For the most extreme case it might be source, binaries *and* blueprints *and* hardware, i.e. an ICBM guide and control system or a core banking solution. My requirements may include the ability to reproduce it from the ground up at any moment in the next 30 to 50 years. Of course I can't introduce some past model of a vacuum lamp in the SCM but again, it is not that I wouldn't want to do it (of course I would want to do something on the lines of `scm checkout --date 19700301 thewholesystem`) but that I can't (in this case both because of limitations of the tool *and* limitations of the physical world).

Re:Data, Images, Binary builds etc.

[tqk]

Why or how I retroactively lost data, I don't know.

Uh huh. Yet another "computing professional" who can't figure out how to burn his $HOME to a CD. I'm so fscking impressed.

How the fsck do you people manage to remain employed?!?

Re:Data, Images, Binary builds etc.

[tqk]

Pictures and video are fluid, They change, maybe release to release.

Gahd, this is stupid. Have you never heard of symbolic links?!? From my .bash_history:

ln -s /dev/null ./.adobe/Flash_Player

Whoever's creating pics and video files provides a link to their latest version, and you tell your code to pull from the link! This isn't even version control related (except on their end). It's fscking basic.

Why are people like you even employed in IT?!?

Re:Data, Images, Binary builds etc.

[tqk]

God I hate people that put bins and bits and images that should be linked and stored on appropriate storage, not archived in a RCS.

Please keep in mind that pre-Vista, Windows didn't actually *have* proper symlinks. NTFS junctions technically existed since NT4, but Microsoft guarded them like a state secret and bent over backwards to avoid making people aware of them. Also, junctions are more like Ext3 hardlinks, so you can't *quite* use them with reckless consequence-free impunity the way you can with real symlinks.

GIGO. Serves you right for relying on a toy OS.

How many malware checkers are you running today?

Re:Data, Images, Binary builds etc.

[Mitchell314]

I'm not a professional, I'm a student in mathematics. Programming is just a hobby of mine. Nor do I have the disk space left to back up everything I own since my computer is old enough to be eligible for kindergarten if it were human. And don't tell me to buy more disk or buy a service, I struggle with affording basic living necessities as it is, so sorry if I can't climb on to your high horse.

Re:Data, Images, Binary builds etc.

[tqk]

Why or how I retroactively lost data, I don't know.

Uh huh. Yet another "computing professional" who can't figure out how to burn his $HOME to a CD.

I'm not a professional, I'm a student in mathematics. Programming is just a hobby of mine. Nor do I have the disk space left to back up everything I own since my computer is old enough to be eligible for kindergarten if it were human.

Ah. Sorry, I assumed too much.

First, you don't "back up to disk". That's just asking for trouble. You back up to media off disk, whether that be tape, CD, or DVD, etc. I use a bash script that calls find, bzip, and afio, then wodim (cdrecord) to create iso images I can burn to CDs. Smiple [sic]. My $HOME seldom hits more than a third of a CD.

Second, my computers are ancient too. They serve me (mostly) well. The CPU du jour is not necessary if you're not running stupid OSs.

Third, I wish the world was less stupid, 'cause then I'd be rich, instead of wasting time pontificating on /. Can't have everything. :-P

Fourth, damn, I wish I was better at math. Good on you!

Re:Data, Images, Binary builds etc.

[Mitchell314]

Heh yeah, math I can do. Unfortunately I decided I liked programming more, but too late to change to a CS major. :)

Re:Data, Images, Binary builds etc.

[gbjbaanb]

I have source code from 1990 in the main app I work with, does that mean I should take that out of my source code repository?

Just because an image doesn't change often does not mean it shouldn't be controlled along with the rest of the source code. Putting it somewhere else simply means you're running a good risk of losing it, getting it confused with other versions (when it does eventually change) or, at best, being a nuisance for all your developers. You need to put everything in your main repo that is your app. If your tool doesn't support that, get a new tool.

Re:Data, Images, Binary builds etc.

[wrfelts]

Finish your math degree. Go as far as you can go on that. (Doctorate, even...) If you can do the math you can outpace most programmers at their own game. Most programmers, as it is, were not trained in college to program. I was trained in Chemistry.

Basic programming may not look like math but almost anything worthwhile being programmed uses math extensively (even when the programmer doesn't realize it!). Understanding the best way to accomplish something mathematically will make shorter work of programming it. Math may not be "the end all" but it's definitely an essential skill.

Programming languages and concepts are much easier to learn than the math so finish there first. Then get a "math job" that also needs some programming on the side. You'll be able to do the switch easy enough.

Re:Data, Images, Binary builds etc.

[wrfelts]

Those who do keep the binaries, partly, because the tool sets change. A patch to the compiler can change the resulting binary. If you have a specific binary in the field that was compiled with one version, you may not be able to duplicate a bug using a binary from a newly patched compiler.

Granted, I don't recommend using a VCS to store all binaries along with the source. That is just asking for trouble. I do, however, store a single "release package" of binaries and other data that relate to a specific source code branch for each officially released version.

This historical reference helps when traditional debugging doesn't work. Sometimes the bug was in the compiler. If you can't isolate the problem to the binary vs. the source code, it can be a nightmare.

It would probably be more efficient to use a traditional file store but using a VCS, if done simply, can be very convenient.

You're forgetting

[Anonymous Coward]

Visual Studio rocks!!! Pwns all this stuff.

Re:Large, complex projects require good source con

[siride]

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

[Anonymous Coward]

[...] 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?

Glip!

[luke923]

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

[euroq]

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

[siride]

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

[mgiuca]

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

[m.dillon]

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

Re:Git could use revision numbers

[EvanED]

I'm not sure how branches play into this, but as someone who used Subversion for a few years and then switched to Git for the last few years, I forgot to mention version numbers when I said what I think Svn does better in another post. (Mostly that post talks about what Git does better, so this is an exception. :-))

The nice thing about version numbers is they are predictable. If you're on revision 100, the previous revision was 99. The next revision is 101. With hashes... there's nothing. If the current revision is 483b3ced, that tells you nothing about what it's parent revision or child revision is.

Now, Git works around this mostly, because you can say 483b3ced^ to go to the previous revision (and actually SVN supports this too because you can say HEAD^). But it's not a full solution. What's the next revision? Git doesn't have a way of getting you that information.

This is not very commonly useful (at least in my experience), and most of the time it is useful is because you're doing what 'git bisect' does natively, but every once in a while at least I hit an edge case where it would be useful to specify "the next revision". And I don't know of a way Git gives you this, even just scanning over the rev-parse man page.

Re:Git could use revision numbers

[Anonymous Coward]

Problems solved with ordinary numbers:

a) You can type them and name them to people in the other cubicle.
b) you can read them and know which one is before and which is after.

Re:Git could use revision numbers

[Tacticus.v1]

I can see a problem with revision numbers though.
if I make a change in my repo, you make one in yours and we both merge to C

which revision gets 101?
which revision then changes its number?

Re:Git could use revision numbers

[EvanED]

That's precisely why most DVCS don't use version numbers, but you'll also notice that the poster who started this thread proposed having a master repository which sets the numbers.

You'll also notice I didn't say "DVCS should have version numbers" in my post, I said "here are the drawbacks with the fact that DVCSs don't (usually) have version numbers."

Also you could look at Bzr... another poster in this thread has elaborated on the way it does numbering in a distributed setting.

Re:Git could use revision numbers

[euroq]

I think your points misses my point: I do like Git, but revision numbers make communication easier. There is no difference between "15.1" and "e209309fff0902930293302920" as far as a unique ID to a software program goes, but there is a difference as far as communication to people goes. A revision number called "mybranch.13" inherently tells me that it is the 13th commit of mybranch, and is also easy to communicate to another person.

Re:Git could use revision numbers

[Anonymous Coward]

While not 100% the same thing as revision numbers, the same thing can really be done with git push hooks and tags. Every push creates a new tag with some monotonically increasing number(read from a file, or what-not). Automatic tags are also useful for determining which commits were included in individual pushes so if you want to know exactly which commits caused the bug yesterday, you can look at the tags for that day to see all the individual commits (regardless of whether they were committed to the user's local repository yesterday or last month).

Re:Git could use revision numbers

[Anonymous Coward]

In Git there is no wrong way.

Take the Linux kernel, developers pull form Linus all the time, Linus pulls from them when a feature is ready for inclusion in Linus' tree.

You can even have circles. A developer pull from Linus' tree, Andrew pulls from the developers tree, Linus pulls from Andrews tree.

How do you propose handling that in your revision numbering scheme?

Re:Git could use revision numbers

[euroq]

In one word: communication.

Revision numbers make communication easier. There is no difference between "15.1" and "e209309fff0902930293302920" as far as a unique ID to a software program goes, but there is a difference as far as communication to people goes. A revision number called "mybranch.13" inherently tells me that it is the 13th commit of mybranch, and is also easy to communicate to another person. Going further, it helps with Blame... lookups which says "this line was changed because of "thisnewfeature.13" and hence "thisnewfeature", instead of having to make awkward lookups of "e203920390293039".

Not every commit is tagged... and it shouldn't be, because that is what commit messages are for.

There is absolutely no software problem that is solved by revision numbers, only people problems.

Re:Git could use revision numbers

[koinu]

I've read that the development on DF switched to git somewhere else. I'm glad that you are not that narrow-minded as the FreeBSD team who chose Subversion only because of its BSDL and their legacy scripts from CVS that you have to touch anyway, when you port something to some other SCM. We discussed it in some unofficial forums what is better (ended up in a flamewar, of course).

Now you can see the direct results of the switch to SVN. They are trying to keep CVS and CVSup alive and they fail. Fortunately, there is portsnap for ports which is highly efficient, but simply does the same as Git but does not have many features like branches and merging of your own changes. World is completely on Subversion by now, but there have been times where Subversion failed and CVSup worked and vice versa.

Now Subversion has 2 ports on FreeBSD. One Subversion port is modified for FreeBSD development. You need to image this! Yeah, of course... let's modify our SCM, because we make a new project! Yeah, ok FreeBSD needs their useless "$FreeBSD$" tag for whatever. As if an SCM cannot determine who did the last change on the file!

FreeBSD could do it better. Even /etc could be on Git, because it offers nice merging possibilities and you don't need any tools like mergemaster or etcupdate.

So far, you've made a better decision going with Git on DF than FreeBSD, in my opinion.

Re:Git could use revision numbers

[bigpresh]

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.

You don't have to use the entire SHA - e.g. for a long unwieldy SHA like a809deeb979c33a7cc9ac48da72a2a22eaa7dc62, you can simply refer to it as, say, commit a809deeb, or even a809 - as short as you like, as long as it's still unique. In most repositories, the first 8 characters should be a pretty safe bet.

Re:Git could use revision numbers

[mfwitten]

Now, Git works around this mostly, because you can say 483b3ced^ to go to the previous revision (and actually SVN supports this too because you can say HEAD^). But it's not a full solution. What's the next revision? Git doesn't have a way of getting you that information.

That question doesn't make any sense, because in absolute terms, there are an indeterminate number of immediate children across every repository and across time.

There are a number of things you could do to narrow the search (such as something like git log --reverse -1 483b3ced..master, but ultimately you'd have to account for merge commits there, too; perhaps the --children flag for git rev-list and git log might be useful).

Re:Git could use revision numbers

[mfwitten]

What's wrong with using git name-rev?

Re:Git could use revision numbers

[complete loony]

If you want to write a commit hook that runs on your master repository, that automatically creates a numbered tag for every push to the master branch. That's fine, you can do that if you wish, using whatever numbering scheme you like. Git is flexible enough to do just about anything.

Personally I would rather wait until I'm certain the code is releasable before assigning version numbers and creating tags. But, to each his own.

Re:Git could use revision numbers

[Co0Ps]

At work we use SVN revision number as the "build" token in the web application version number. E.g. 5.3.5627 where 5627 is the revision number. It's very easy to see what revision is currently deployed and it's very easy to communicate this version number to other people. You also get a very good idea of "how far" it is between revisions in the revision stack when hearing their numbers.

Re:Git could use revision numbers

[PeterBrett]

Use `git describe':

[peter@harrington gaf (master)]$ git describe
1.7.1-20110619-169-gc9d4f66

This returns a string containing the most recent tag on the branch (1.7.1-20110619), the number of commits since that tag (169), and the first seven hexadecimal digits of the commit SHA-1 (c9d4f66).

Re:Git could use revision numbers

[complete loony]

Perhaps with a small number of commits like your 13 example, this would work fine. But what about r32185? Are you going to sit there and count them all by hand? No, you'd use your source control tools to find it. Sure e209309 or 18d3ba doesn't tell you which commit came first, or which tagged build it was first included in. But git's command line tools can answer those questions.

Yes, the learning curve is steeper. But the primitives that git is built on are actually quite simple and understandable. And the tools that have been built around them are very powerful indeed.

With git, the server the commit is currently stored on is much less important than who wrote it, when and what they changed. In a project the scale of the linux kernel, a commit might be copied around a large number of repositories before finally being blessed by Linus or one of his lieutenants and included in the next release. In all of those moves, the commit id will not change. But the branch it has been included in, and perhaps even the order it was merged will change.

More fundamentally in git the focus is not on controlling the history of a specific central branch. But on making it easy to accept and apply patches from anyone. Recognizing that in a large project, merging can be more common than committing.

Re:Git could use revision numbers

[Anonymous Coward]

What's stopping you from tagging all commits?

Re:Git could use revision numbers

[minkie]

Revision numbers are easier for humans to deal with. For example, here's a common flow I use every day:

$ hg pull
$ hg log | less { see some change I'm curious about and note the change number }
$ hg export 3742 | less

With change numbers, it's easy to remember 4 (or even 5) digits for the time it takes to type the export command. If I only had hashes, I'd have to copy-paste the string. Things like this matter less to people who only use GUIs. For command line folks, however, being able to easily read, pronounce, remember, and type change numbers is essential. Even if you're just talking with other people, it's a lot easier to say, "Oh, I see what happened, in change 2456, you did..." than to refer to hash strings.

I've used rcs, cvs, clearcase, perforce, dabbled in svn, dabbled in git, and am currently using hg. Of the centralized bunch, perforce is my favorite (not free, but reasonably priced and amazingly excellent tech support). I can't see anybody wanting to use svn for any new projects today. When it first came out, it was a a significant improvement over cvs and people naturally flocked to it, but there's just so many better alternatives today.

Clearcase is an interesting beast. For sure, it's overpriced bloatware that's on life support, being kept alive mostly by big legacy customers with neanderthalic IT and Release Engineering departments who still believe IBM can do no wrong. But, it did have some interesting ideas. That every revision of every file exists simultaneously in the file system namespace is really powerful.

Between git and hg, I'd say they are fundamentally identical in capability, but I find the hg command set easier to get my head around. All the people who say, "X is the best possible vcs. I used to use cvs and when I switched to X my sex life improved overnight", fail to understand that "X is way better than cvs" is true for pretty much any value of X, and says nothing about the relative merits of the various X instances.

Re:Git could use revision numbers

[Anonymous Coward]

git-tag

Re:Git could use revision numbers

[siride]

That's what tags are for. As for getting a sense of "how far", a proper version numbering scheme would impart just as much, if not more, information. However, if you still want something like that, you could easily count the commits and append that to your version number. Some projects like to use the SHA1 hash as the tail of the version number. You could combine both easily.

Re:Git could use revision numbers

[Anonymous Coward]

You're using the wrong tool for the job. You need a centralized VCS like Subversion.

Re:Git could use revision numbers

[Phleg]

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.

Oh come on. Ctrl+C, Ctrl+V is "unwieldy"?

I have used git exclusively now for over three years, and I completely forgot that incremental version numbers even used to exist. It's a bullshit non-issue..

Re:Git could use revision numbers

[Anonymous Coward]

Or you could just use tags with useful names... released-to-prod-server-2011-01-03 is way more useful than 23.44.859...

Re:Git could use revision numbers

[EvanED]

I have a couple objections to your arguments.

First, I feel that it falls into place with one of the big pieces of what I see as the Unix philosophy (or at least very common in Unix tools) and which I almost always very much disagree with: refuse to be helpful in the common case if there are cases either where you know you can't be helpful or cases where you'll make mistakes. (In this case, "common case" = "no branch from this point".)

Second, what if I'm only interested in a single branch? There there can't be more than one child, because the second child is on another branch. If I'm on the commit that the branch head points to (I'm not sure the technical Git term), then there are no children, otherwise there is exactly one. If I took a branch from the current head, doesn't matter. I'll see the merge commit when I get there, or if it hasn't yet been merged, it doesn't matter one iota.

Third, take Subversion's revision numbers in particular. Since that number is global, if you cycle through them you will eventually hit every child. Now, this argument is not terribly compelling because you won't know when you're there without some inspection, but you will hit it. (On a related note, how do I get a list of every commit ever made to a Git repository, on any branch? I have no clue. With Subversion, it's easy -- you just ask for the log higher up the tree.)

How much do these things matter in actual use? Very little, especially with the graphical tools that are available (for both Git and Subversion). But it's not zero, IMO.

Re:Git could use revision numbers

[Anonymous Coward]

git describe will give you a count of commits since a certain tag. You can use it as a poor man's revision number.

Re:Git could use revision numbers

[GlobalEcho]

Three counterpoints:

  (1) Facile typists can type "3.18" much faster than they can do two focus changes and two chorded keystrokes
  (2) Humans are better at recognizing simple (and short) numeric patterns than alphanumeric strings.
  (3) Some people still use their voices, e.g. in face to face conversations and on telephones.

Denigrating this as a "bullshit non-issue" is arrogant and ignorant of human psychology. Other posters suggesting the use of tags are on a more reasonable track.

Re:Git could use revision numbers

[KiloByte]

"git describe". It will give you a revision number since the last tag, plus a disambiguation hash. That number can be then used as a commit reference.

Re:Git could use revision numbers

[euroq]

Perhaps with a small number of commits like your 13 example, this would work fine. But what about r32185? Are you going to sit there and count them all by hand?

Actually, other modern VCSs with revisions would use branch/tags to create the revision numbers. So it would be "mybranch.500", which means it's a revision in "mybranch", or "release1.5-200", meaning the 200th commit after release1.5. This also helps when using the blame tool to find out why a certain line was changed, as you could see that this line was changed for "somefeature" inherently (although admittedly that's a minor caveat).

In a project the scale of the linux kernel, a commit might be copied around a large number of repositories before finally being blessed by Linus or one of his lieutenants and included in the next release. In all of those moves, the commit id will not change. But the branch it has been included in, and perhaps even the order it was merged will change.

As I stated in the original post, this idea would only work with a "centralized" or "master" repository. And it would only be a convenience label; the SHAs would still exist as normal. The Linux kernel repository is not centralized.

Re:Git could use revision numbers

[euroq]

Nothing... but I would like to flag the "master" repository to automatically do it for me. I think tagging everything is overkill. But in any case, our build system is setup to tag builds so we do have some semblance of this.

Re:Git could use revision numbers

[mfwitten]

how do I get a list of every commit ever made to a Git repository, on any branch? I have no clue. With Subversion, it's easy -- you just ask for the log higher up the tree.

Like this: git log --all

RTFM :-)

Second, what if I'm only interested in a single branch? There there can't be more than one child, because the second child is on another branch.

What you call a `branch' here is not what git calls a `branch'. In git, a branch is simply a pointer (as a nice human-readable name) that points to a particular commit object at any given time, and this pointer's value can be changed at any time; it just provides a convenient way to refer to a commit, and in practical terms it is all that is necessary to be productive (tags take care of the rest).

What you're describing as a `branch' is a much more absolute concept, something that would better be called a `linear ancestry' or `line [of development]', and calculating that line is the crux of the problem; you're begging the question by assuming you already know exactly what you want to calculate.

Consider the history in Figure 0 (I would have inlined it, but Slashdot's commenting system erroneously flags it as spam).

In git's terminology, branch `master' as shown in the diagram just [currently] means commit `D0', and branch `some-branch' just [currently] means commit `E'. There are 3 linear ancestries or lines (see Figures 1, 2, and 3 at the same link).

As you can see, the first 2 lines are traversabe from the same git branch, `some-branch'.

Now, let's say you want to know "the" child of commit `B'. Firstly, which line are you talking about? Well, you must already know which line (or set of lines, as you'll see) that you want to consider. As per my last comment, you could do something like the following (where I've simply replaced `483b3ced' in the original with `B'):

git log B..master --reverse -1

The command says:

* git log: show me log information for...

* B..master: the set of commit objects reachable from `master' but not reachable from `B' (this would be {D0,C0}),

* --reverse: order that set from oldest ancestor (C0) to the newest descendant (D0), but...

* -1: display only the first in that ordering (C0).

Now, in this case, you can actually be a bit more ambiguous with your lines and still get the same answer:

git log B..some-branch --reverse -1

The command says:

* git log: show me log information for...

* B..master: the set of commit objects reachable from `some-branch' but not reachable from `B' (this would be {E,D0,D1,C0}),

* --reverse: order that set from oldest ancestor (C0) to the newest descendant (E), for a total ordering of something like (C0,D0,D1,E), but...

* -1: display only the first in that ordering (C0).

What about the third line of development, though? Assuming you know (unlikely) that `D2' comes after `B' in a line, consider:

git log B..D2 --reverse -1

The command says:

* git log: show me log information for...

* B..master: the set of commit objects reachable from `D2' but not reachable from `B' (this would be {D2,C1}),

* --reverse: order that set from oldest ancestor (C1) to the newest descendant (D2), but...

* -1

Re:Git could use revision numbers

[mcvos]

There's no guarantee of uniqueness, however. Different people could be using the same version number.

Re:Git could use revision numbers

[euroq]

The guarantee of uniqueness would come from the master repository; see the OP. And it's not necessarily unique, it's just a label that says 15th commit since branch2 or something similar, as in "branch2.15".

However, I should also point out that the only guaranteed unique identifier would still be the SHA. The reason being is that, Git gives one the ability to "rewrite history", which is what happens whenever you have to do a "force" push. In this case, the revision numbers would change.

So once again, I think that they would be convenient as labels for people, but they would not be replacements for SHAs, and they would not be the same as SVN revision numbers. Just a better way of describing the history.

Re:Git could use revision numbers

[Anonymous Coward]

You could do this yourself with a post-receive hook on your main repository and a new kind of ref. (For example, refs/revisions/3)

I didn't really understand the numbering scheme you tried to illustrate in your diagram, but assuming your numbering system is deterministic and can tolerate non-linear history you should be able to implement it.

You can configure what types of ref git will fetch when it retrieves new items from a remote, so you can expand the default wildcard including refs/tags/* and refs/heads/* to include refs/revisions/* too. Then when someone tells you "check out revision 3" you can just say "git show refs/revisions/3".

Of course, you would eventually end up with lots of files in refs/revisions which might degrade performance. Using some kind of sub-directory hashing scheme would mitigate that.

Git is Easy

[deisama]

#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

Re:Git is Easy

[Anonymous Coward]

That would be because TortoiseGit is a direct port of TortoiseSVN, and that feature has always existed in TortoiseSVN.

Re:Git is Easy

[DrXym]

TortoiseSVN is a direct port of TortoiseCVS so what is your point? Each Tortoise* package is similar at the top level and shares a heritage and some tools but they have to deal with radically different version control systems underneath.

In the case of creating a repo, the meaning is fundamentally different in Subversion than it is from Git. In Subversion when you create a repo you are creating a master repository folder that checkins, tags & branches get stored in when you commit from a snapshot. But your snapshot is checked out somewhere else. In Git when you create a project, the project is the repository and it is also the snapshot of the active branch. It's a superficially similar menu item that has a different underlying meaning.

Re:Git is Easy

[outsider007]

I submit that the real reason you like Git is that GitHub is pretty. It has a nice design. If the site worked half as good as it looked they would really have something. Unfortunately most of the features are ill-conceived and/or broken.

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

[LoudNoiseElitist]

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.

Re:It's not perfect, but it ain't bad either...

[DrXym]

I'm not afraid of a command line but I would take a simple GUI over the command line every single day of the week. The command line would still be there if absolutely required, e.g. for that one time in a blue moon when you need to do some mad merge. The rest of the time a GUI should service what developers do on a daily basis. Furthermore, when it is integrated into a tool such as Eclipse (as EGit is), it means it works perfectly well with other functionality such as code refactoring, blame annotation, code comparison and so on.

hillbillies with cultural agendas

[epine]

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.

Eclipse has adopted Git [for] for Eclipse projects

[Anonymous Coward]

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.

PostgreSQL CVS-git conversion

[greg1104]

I had a small role in getting the PostgreSQL project to convert from CVS to git. There's a good summary of what happened at Lessons from PostgreSQL's Git transition. With a pretty conservative development community, the bar for converting from CVS to git was set pretty high: the entire CVS repository had to come through, such that every single release ever tagged could be checked out and get exactly the same files as checking it out of CVS (a little binary diff tool was used to confirm). With around 15 years of history in there, that took some upstream fixes to the cvs2git tool to finally accomplish; it took just over a year to work out all the details to everyone's satisfaction. My checked out copy of the current repo is 272MB right now, so neither small nor giant.

I would say that everyone who works regularly on the code is at least a little bit more productive than they used to be, with the older CVS experts having seen the least such improvement. But some people are a whole lot more productive. I'd put myself in that category--my patch contribution rate is way up now that it's so much easier to pop out a branch to hack on some small thing and then submit the result for review.

And the conversion seems to have improved the uptake of new developers getting involved in working on the code. Having to deal with CVS was a major drag for younger developers in particular, and Subversion is equally foreign to most of them now. As suggested in the article, anyone under 25 will only touch a corporate style CVS or Subversion repo if dragged kicking and screaming into it. As more of that generation rises through IT, old style repos will continue to get shredded at a good rate every year. It could have been any of the DVCS systems that ended up in this position, but git was the one that got the right balance of feature, innovation rate, and publicity. Now that it's got such a wide user base, too, I don't see any of the other VCS software options competing with it successfully in the near future.

Re:PostgreSQL CVS-git conversion

[euroq]

Interesting.

I would argue to the old-school developers that there is absolutely, positively, 100% no reason to ever use CVS in 2011. There is absolutely no advantage that CVS has over modern VCS's.

Re:PostgreSQL CVS-git conversion

[DrXym]

There are very minor advantages to using CVS such as per-file labelling, and cherry picking what files / folders to checkout. But you have to sacrifice a whole lot for those minor features.

At the very least CVS codebases should migrate to Subversion but preferably a DVCS should be considered. The biggest issue is it's all very well saying these things but in a production environment it is trying to find the gap where you can transition is not so easy. It's not just a case of running cvs2git / cvs2svn and everything happens by magic. You have to set up new servers, you have to change all the release engineering scripts, you have to retrain staff, you have convince management to give you the time, you probably even want to refactor everything in a sane way first. The end goal is obviously desirable & IMO completely justifiable but it's a lot of effort so it's no surprise that some places are still stuck on CVS.

Re:PostgreSQL CVS-git conversion

[Anonymous Coward]

Drama queen. They are all more or less equally complex.

Re:PostgreSQL CVS-git conversion

[mfwitten]

You can cherry-pick which files/folders to checkout in git as well; see the `show' and `checkout' commands. Also, you could just create tags for conveniently referring to the revisions from which you want to `show' or `checkout' a particular file.

Re:PostgreSQL CVS-git conversion

[Slashdot Parent]

Interesting.

I would argue to the old-school developers that there is absolutely, positively, 100% no reason to ever use CVS in 2011. There is absolutely no advantage that CVS has over modern VCS's.

I'm old-school for sure, and have done plenty of projects stored in CVS back in the day. That being said, I'll tell you that the only reason anyone still uses CVS is that it is a pain in the ass to convert years upon years of project history into another VCS.

CVS is fundamentally broken and should never be used. I can't imagine that anyone has voluntarily used CVS in the last 10 years or so.

Android

[drmacinyasha]

Another major push for Git: It's used by Google for Android (Google uses Gerrit Code Review rather than regular pull requests) and has subsequently been used by many Android development teams (such as CyanogenMod) even if not for Android ROMs themselves, but just for apps and whatnot.

And yes, Github makes it incredibly easy to get large groups collaborating together on projects using Git. No doubt about that.

Re:Eclipse has adopted Git [for] for Eclipse proje

[greg1104]

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

You missed the call, it was a while ago. I considered TortoiseGit mature enough to use around V1.3, which was January of 2010. The upward spike in downloads shown on their page, which really took off around V1.2, shows quite a few people agree.

Re:Eclipse has adopted Git [for] for Eclipse proje

[EvanED]

I've been using TortoiseGit for some time, and it's pretty awesome.

I only remember one problem. I'm not sure exactly what happened, but it had something to do with the combination of (1) trying to hide the index from you (which I'm actually totally behind in its case) and (2) something getting into the index by other means. I think what I was getting was an empty commit dialog even though there was uncommitted stuff in the index. But that was easily solved via the command line, which may have been how I got into that state to begin with. That problem was a while ago so I don't recall really what happened. :-)

Re:Large, complex projects require good source con

[Robert Zenz]

You have a small project/sprint? Just cp your source code periodically (or rsync).

Never, ever, again, no. Whatever I code, big or small, it ends up in SVN or GIT. Never again will I be searching files for older revisions, and I can't understand how some people can handle professional projects without it.

Oblig

[Haedrian]

http://www.youtube.com/watch?v=HtyO4tmpPdk

Re:Oblig

[Lennie]

I actually expected this one:

http://www.youtube.com/watch?v=4XpnKHJAok8

Octopus.

[pizzach]

Thank you git for giving me reasons to use such an awesome word. In normal conversation.

For those wanting version numbers

[shish]

have you considered "git tag" + "git describe"? I give each release a version number tag (eg 1.21.1), and then "git describe" gives a "last tag + offset + UID" string (eg 1.21.1-35-g86897b0) which works wonderfully for things like package names (eg libfoo_1.21.1-35_amd64.deb)

Re:Sac longchamp

[Guy Harris]

sac longchamp have superior craftsmanship and design ,so that many people like to own them blah blah blah

But do they support any workflow?

So it's true?

[Anonymous Coward]

And here I thought it was just me thinking the gits were on the rise!

try SmartGit

[Barryke]

I find SmartGit more useful for day-to-day stuff.
I have TurtoiseGit installed (and it works) but i never use it. Having the correct icons show up in Explorer is nice though.

Whatever happened to to Tom Lord's Arch?

[Relyx]

Tom Lord, developer of rival Arch must be spitting blood at the success of Git.

I followed Arch's development back in 2004 and quickly lost interest. The last crazy thing I remember was Tom trying to build a home-brew LISP derivative *into* his version control system. It was going to revolutionise everything. He even wrote a long manifesto-cum-design document in three parts. At that point I gave up and moved to Subversion. I just wanted a modern version control system that worked.

Re:Whatever happened to to Tom Lord's Arch?

[paskie]

Actually: http://wiki.bazaar.canonical.com/HistoryOfBazaar Bazaar pretty much evolved from GNU Arch, though it is of course a very different beast now and there is AFAIK no shared code - but the developers migrated there from a GNU Arch branch and they took some ideas with them, so it still can be seen as a spiritual successor. :-)

Re:Whatever happened to to Tom Lord's Arch?

[Anonymous Coward]

He's doing something different nowadays:

http://www.tomlordmuscle.com/ (NSFW!!!!!!!!!)

Re:Whatever happened to to Tom Lord's Arch?

[Anonymous Coward]

" At that point I gave up and moved to Subversion. I just wanted a modern version control system that worked."

Then why did you move to Subversion if you wanted something that just worked? Subversion has merging issues, as in Subversion can miss merges. It's a problem that's not easy to fix since merge tracking and true renames were deliberately left out of Subversion's initial architecture.

Re:Whatever happened to to Tom Lord's Arch?

[Anonymous Coward]

Other people turned it into Bazaar.

Re:Whatever happened to to Tom Lord's Arch?

[Anonymous Coward]

"I gave up and moved to Subversion. I just wanted a modern version control system that worked."

Good luck, with subversion.

Re:Whatever happened to to Tom Lord's Arch?

[Anonymous Coward]

Arch was much crappier compared to Git. I've even used arch for almost 2 years. It seemed better than SVN, but,

1. It had those massive patch directories which broke on Windows (path length limit). This type of structure was also *fragile*.
2. It had revision numbers (yuck)
3. It was not possible to checkout in-place

Comparing Git to almost anything is wrong. Some people bitch that "Git is not enough", etc. etc. Git is simply a multiple revision file system. That's it. Every tool is built on top of the basic premiss of individual, complete filesystem snapshots. Git is simplicity at its finest.

If one were to compare Git to any other revision file system, including CVS, Git is the UNIX as the rest is Windows. Git is the small utilities, while the rest is "monolithic heap of stuff".

Re:Whatever happened to to Tom Lord's Arch?

[Anonymous Coward]

What happened with Arch? One path was Bazaar; on the other, I wrote git-archimport ;-) http://www.kernel.org/pub/software/scm/git/docs/git-archimport.html

Re:Eclipse has adopted Git [for] for Eclipse proje

[DrXym]

Git on Windows has gotten a lot better. You need to install msysgit and then TortoiseGit on top. With those two things you're more or less free to do everything visually. I think TortoiseGit is still rough around the edges compared to TortoiseSVN though.

In Eclipse you now also have top tier support for Git through the EGit plugin. This is sitting over a pure Java implementation of git called JGit (i.e. no need for msysgit). It works pretty well and in the manner you would expect if you've ever used a VCS with Eclipse before. JGit and also powers Gerrit which is a git server and web app that slots a code review & approval system into the workflow.

Doesn't matter

[warrax_666]

(Just for clarification: I've used both Bazaar and Git extensively.)

"Externalized" branches are still a bad idea. I've admin'ed a Bazaar installation and the fact that every group had its own convention for laying out branches in the file system was a complete pain in ass. (Some had multiple levels of directories, others only one, etc. etc.). It's bad from a scripting perspective and from a consistency perspective. It does not add any functionality that you actually need, but it does add a lot of incidental complexity.

There's also the fact that disconnected development requires you to predict in advance what branches you're going to need. Having all the branches in the same repo (i.e. it costs nothing to sync all of them) is a huge advantage here.

Re. revision numbers: Revision numbers are a fundamentally flawed model in a distributed world. In a distributed system there can be no consistent numbering unless you can and do enforce a global total order... which neither Bazaar nor Git do. The only sane thing to do is to use a "content" hash. The fact that Bazaar just lies to you and pretends that there is a global total order is not a plus. In practice, it led to unnecessary confusion because you always have to refer to branch and revision number, but people being what they are, they often forget that. The fact that a content hash identifies a given revision globally and uniquely means that you even don't have to care where you get the repository data from as long as the hashes match.

IME Bazaar is also a lot buggier than Git, presumably because of an internal model which is a lot more complicated than Git's. It's got a huge test suite, but we regularly ran it various obscure errors. It's also (still!) a lot slower than Git.

Re:Doesn't matter

[mgiuca]

I agree with a lot of what you said, so take my silence on any issue as agreement.

It does not add any functionality that you actually need, but it does add a lot of incidental complexity.

I understand the concern from a scripting standpoint. But I wouldn't say it does not add useful functionality. On the remote side (when a server stores branches in different directories), it gives me a unique URL handle on each branch. This is invaluable, as I can say "push from here up to lp:myproject:mybranch", for example. On the local side, it lets me have a physical directory for each branch: I often work in multiple branches simultaneously (e.g., if I am working on a feature and find a bug in trunk, I'll Alt+Tab to my already-open trunk window and fix it there and commit it -- this saves me from the temptation of fixing a bug in the feature branch, which would bloat the feature branch unnecessarily.)

Re. revision numbers: Revision numbers are a fundamentally flawed model in a distributed world. In a distributed system there can be no consistent numbering unless you can and do enforce a global total order... which neither Bazaar nor Git do ... The fact that Bazaar just lies to you and pretends that there is a global total order is not a plus.

You're assuming that revision numbers need to be globally consistent in order to be useful. Once you understand how Bazaar's (admittedly complicated) revision numbering scheme works, you can find them useful even though they aren't globally consistent. Bazaar does not "lie" to you and it does not "pretend there is a global total order," ... you must have read the wrong manual. Bazaar is quite clear on the fact that revision numbers are specific to a branch. And yes, if you're communicating them, you do need to refer to the branch name and the revision number (or, if you don't, it could reasonably be assumed you are referring to the trunk). Here are some reasons why having systematically and contiguously-numbered revisions is helpful:

- Much easier to type or say than a hash (say I am communicating verbally, "hey Mike, there's a bug in trunk r135").
- Obvious order in most cases (142 clearly precedes 164; 142 clearly precedes 142.2.53).
- Obvious which revisions are the "important ones" (13 and 183 are on this branch's main line -- for the trunk this means they are stable commits; 45.1.14 was clearly an unimportant commit to a branch that was merged into this one).
- Most importantly, for a given merge commit, obvious which parent was the previous commit to this branch (for r14, it is r13) and which parent was from the branch that was merged in (say, r11.1.5). This is a critical advantage of Bzr over Git -- Bzr trees keep their "shape" whereas Git trees are just a pile of commits with parents.
- The "distance" between two commits is clear; it is obvious that 13 and 15 are much closer together than 13 and 165.
- For any two branches, all commits made before the branching point (where the two branches split) have consistent revision numbers.

All of this far outweighs the fact that you have to be educated and careful about the fact that a Bzr revision number means different things in different branches. It takes some getting used to, but so does referring to everything by a long and meaningless series of letters and numbers. Even Linus agrees: he plans to add "generation numbers" (a very weak form of Bazaar's revision numbers) and in this email, he stated that "the lack of [generation numbers] is literally the only real design mistake we have."

Re:Doesn't matter

[Anonymous Coward]

You're assuming that revision numbers need to be globally consistent in order to be useful. Once you understand how Bazaar's (admittedly complicated) revision numbering scheme works, you can find them useful even though they aren't globally consistent.

Emphasis mine.

Bazaar does not "lie" to you and it does not "pretend there is a global total order," ... you must have read the wrong manual. Bazaar is quite clear on the fact that revision numbers are specific to a branch. And yes, if you're communicating them, you do need to refer to the branch name and the revision number (or, if you don't, it could reasonably be assumed you are referring to the trunk).

Again, note the emphasis.

- Much easier to type or say than a hash (say I am communicating verbally, "hey Mike, there's a bug in trunk r135").

Ok, I will grant you the verbal issue. But how do you know that Mike's trunk is the same branch as your trunk? Does Arch enforce that "trunk" always refers to the same branch across all clones? If so, how do you merge two separate repo's into one? Additionally, how does bzr allow you to find all branches that contain r135, either through merging or cherry-picking?

- Obvious order in most cases (142 clearly precedes 164; 142 clearly precedes 142.2.53).

Why is order relevant? It's supposed to be a distributed (i.e. parallel) system, right?

- Obvious which revisions are the "important ones" (13 and 183 are on this branch's main line -- for the trunk this means they are stable commits; 45.1.14 was clearly an unimportant commit to a branch that was merged into this one).

Yeah, right. So commits don't matter until they hit a release branch? Given most software release practices, I'd rather say that single-component numbers (i.e. "trunk") should never be important, as all the development and testing should have been done on separate branches.

- Most importantly, for a given merge commit, obvious which parent was the previous commit to this branch (for r14, it is r13) and which parent was from the branch that was merged in (say, r11.1.5). This is a critical advantage of Bzr over Git -- Bzr trees keep their "shape" whereas Git trees are just a pile of commits with parents.

Git is not about trees. Incidentally, neither is software development. Ancestry is not nearly as important as progeny, especially in a distributed environment.

- The "distance" between two commits is clear; it is obvious that 13 and 15 are much closer together than 13 and 165.

Yet, there may be more commits between 13 and 15 than between 15 and 165. Or does the Bzr revision number advance with the number of commits from a merged branch?

- For any two branches, all commits made before the branching point (where the two branches split) have consistent revision numbers.

For Git, this is true even across merges.

Re:Doesn't matter

[warrax_666]

I agree with a lot of what you said, so take my silence on any issue as agreement.

I see what you did there. You're just trying to not represent any positive arguments made for Git, while being free to supply whatever counterarguments you think you have in favour of Bazaar. If you're going to do that, you're just being disingenuous -- which is to say: "not constructive".

Oh, and "Linus thinks it's a good idea" is not a good argument. (Hopefully) we're arguing on technical merit.

It think the AC answered most of your other points.

Re:Doesn't matter

[mgiuca]

I see what you did there. You're just trying to not represent any positive arguments made for Git, while being free to supply whatever counterarguments you think you have in favour of Bazaar. If you're going to do that, you're just being disingenuous -- which is to say: "not constructive".

What? That's how arguments work ... you accept any valid points the other guy has and move on. I wrote that paragraph so that I didn't have to waste time copy-pasting every line of your comment that I agreed with and writing "I agree" underneath it. I find it odd that you took offense to it. But if you simply require it...

"Externalized" branches are still a bad idea. I've admin'ed a Bazaar installation and the fact that every group had its own convention for laying out branches in the file system was a complete pain in ass. (Some had multiple levels of directories, others only one, etc. etc.). It's bad from a scripting perspective and from a consistency perspective.

Fair enough.

There's also the fact that disconnected development requires you to predict in advance what branches you're going to need. Having all the branches in the same repo (i.e. it costs nothing to sync all of them) is a huge advantage here.

Fair enough.

IME Bazaar is also a lot buggier than Git, presumably because of an internal model which is a lot more complicated than Git's. It's got a huge test suite, but we regularly ran it various obscure errors. It's also (still!) a lot slower than Git.

Fair enough.

There, did that satisfy your need for me to specifically address every point?

Oh, and "Linus thinks it's a good idea" is not a good argument. (Hopefully) we're arguing on technical merit.

Absolutely ... if "Linus thinks it's a good idea" was a good argument, then Git would win by default. There's no sense in doing something just because Linus says so. That's why I presented my argument and said "Even Linus agrees" -- in other words, Bazaar does it this way, and Git doesn't, and I think they made a mistake (and I explained why, with a lot of detail and a lot of examples), and also, in addition, notwithstanding all of my other arguments, the creator of Git agrees with me too).

And ironically, you have accused me of not addressing your points, yet you didn't say anything about all of the other points I made in my post. Good day, sir.

Community matters ... more

[Anonymous Coward]

Community matters.

I don't think that too many really believes it's better than other DVCS. Instead it is exactly these the facts: Eclipse adopts it. They adopted it simply because community is large and getting bigger.

Same thing with programming, clever programmer comes up a nifty solution but usually too late. Community on the other hand has already adopted something that was there already, usually hacked together in a hurry. In the end enterprises etc. will adopt the one with bigger community, while it might be really shitty underneath. (Want examples? Look at the CMS floating around, haven't seen any that is programmer friendly with large community)

git ?

[Anonymous Coward]

True Git !

The Rise of Git...

[stewbacca]

...is due to the influx of British entertainment in America. The Harry Potter series uses "git" a lot, as well as my 2nd favorite British-ism, "numpty" (first being, "all sixes and sevens" which barely beats out not understanding what somebody is "on about" and the ever-confusing, "my father is called William" as opposed to him being named something.

Oh wait, this is a thread about some nerdy open-source stuff? My bad. Carry on.

Re:The Rise of Git...

[Anonymous Coward]

I prefer all sixes and nines. Nothing beats chowing down on a woman's wet twat (or even her brown starfish) while she deep throats your member and fondles your balls and fingers your asshole.

Re:TortoiseGit

[mike.rimov]

I used to have lots of problems to when I first tried TortoiseGit a little while ago, but then it suddenly stabilized. I haven't had a crash or failure from it for a while now. Might want to give it a try again.

The Cult of GIT

[Anonymous Coward]

I have seen open source projects like GNOME convert from subversion to git. Many of the git users were arrogant about the greatness of git. They all felt this way because Linus create git just like the Linux kernel. However, this does not mean git is better then others, such as, Mercurial.

git is simple to start with

[drolli]

And thats it.

For the most simple task, namley insuring yourself against loosing some version of some file in the process of editing it, git has incredible low requirements for understanding, infrastructure and a very good support for plain local operation.

I explained simple git usage in 10Minutes a colleague who never use a VCS before how to manage his files.

Re:git is simple to start with

[Lennie]

Many do say it is easier to learn git if you've never used a VCS before.

Re:git is simple to start with

[drolli]

Yes. Could be otherwise your expectations get in your way, but that is exactly my point. If you are *not* a full time project responsible for a large project, then git may be enough.

The pains and necessity of moving to Git

[Qbertino]

Me and my buddy are currently moving to Git as the center and foundation of our web development pipeline.
And while I have to hand it to Linus that distributed is the way to go nowadays I also have to say that there are quite some obstacles when attempting the switch.

1st of all: For n00bs in Git or Versioning in general there is still a lack of 'hand-holding' when it comes to finding the correct strategy. Switchers do need a little help whilst on the way to noticing that their brain has been damaged by thinking in concepts of centralised versioning.
For example it was a bit of a hassle to find a correct zero-fuss substitute for 'svn export' in Git. Export is needed for web development, especially in enviroment where not everything is handled by a CI server or a build system. Curiously enough, this problem forced us to understand Git better, in that everything that is considered a big deal in centralised enviroments like SVN is considered standard in-between/throwaway procedure in Git. Turns out best way for us to do an export in Git was to git clone a working tree, copy our deployment stuff and delete the entire cloned repository again.

2nd: Usability and real-world scenarios/examples of usage in the docs that take non-kernel development scenarios into concern. (This is simular but not exactly the same as point 1) While I have to admit, documentation is improving by leaps and bounds as we speak, there are still some gaps to close in this department. The PDF version of the Git book sucks and I still find the hurdles in understanding Git usage models and terminology to difficult to understand intuitively and not explained good enough for the versioning/decentralised layman.

3rd: Tooling. Tooling has improved massively in the last 2,5 years but as far as my spoiled ass can tell I could still use some neater FOSS Git Gui options than the ones available. Git Tower for Mac OS X is my benchmark here. It's an awesome commercial tool, but I'd like something like that in x-plattform FOSS. ... Did I mention I consider myself spoiled? :-)

All in all I think in the recent Thin Client / SOA craze under a new name called 'cloud-computing' - which appears to finally catch on full scale - there is no alternative in moving to distributed versioning in order to keep your shit under control as a computer professional.

Might aswell use Git for that. I expect to have all my stuff - code and documents - versioned and pipelined by the end of the year, in multiple repositories and lingering cloned across various on- and offline drives, archived, backuped, stored and versioned. Completely independant of any computer I may be using at the time.

It that respect the pain of going Git full scale is more than worth it.

My 2 cents.

I love how you nerds

[Anonymous Coward]

love to passionately rally around stupid causes that nobody else cares about.

Git is not my favorite, but it beats SVN

[rafe.kettler]

Subversion is so annoying to use that it boggles my mind. You have to be incredibly deliberate in your workflow or you're screwed.

Intermediate stages before pushing to a server are a boon for the clumsy and hasty like me. I often instinctively run the last command when I want to test a program, and sometimes it's not `python x.py`, but `svn ci -m "blah blah blah"`. In Git, as with many other DVCSs, local commits (and the ability to change commits after the fact) ameliorate this issue. Also, the ability to be able to work and snapshot your progress as you go even while offline is incredibly useful.

There's also a lot more about svn that can be annoying. For instance, the output of `svn log` is not paged by default, so all you get is a massive info dump with absolutely nothing usable because your terminal can only hold so much output history. This is especially frustrating over ssh.

Basically, while svn is definitely my favorite client-server VCS, it still has a lot of problems and is far less safe and simple than Git or another DVCS.

What does Git, Got?

[assertation]

I've used CVS and Visual Source Safe ( with SQLServer the only two pieces of MS Software I will ever praise ).

VSS was easy and intuitive to use. Like everyone CVS is a PITA and I feel like I manage my files instead of it managing for me.

What does GIT have over other version management systems?

Easier to use? Easier to install?

Re:What does Git, Got?

[Phleg]

What does GIT have over other version management systems? Easier to use? Easier to install?

Not irreparably broken.

Re:What does Git, Got?

[assertation]

What does that mean? You might just sell me

Re:What does Git, Got?

[PJ6]

You just praised VSS and lost all your developer credibility.

Please hand in your nerd card. I'll show you to the door.

Re:What does Git, Got?

[assertation]

Highschool girls evaluate themselves and manipulate others by how "cool" they area, for example, if the pretty girls wear a particular label of clothing.

Comments like yours are the the IT equivalent of adolescent girls.

I'm not a nerd, I'm a professional programmer and I like programming. I'm a grownup who thinks for myself, even if the cool girls don't like it.

I like VSS because it does the job and it is easy to use. More, of substance, doesn't need to be said unless you actually have an answer to my open minded question ( a quality you will benefit professionally and personally by cultivating )

Re:What does Git, Got?

[PJ6]

It has nothing to do with what's popular or cool. VSS has been judged terrible by a whole lot of objective criteria. I'd list them all out here, but the issue is so old and settled it'd be beating a dead horse. It's really a laugh that you say that people who have arrived at this consensus are just not open-minded.

I know your type - the entrenched, isolated programmer who doesn't explore outside of what's in his own little pond. Maybe you even pronounce C# "C hash". Without even seeing your work I already know you're not worth your salary.

Re:What does Git, Got?

[Slashdot Parent]

I've never used VSS. Does it work outside of Windows? Anyway, VSS is abandonware. If memory serves, it doesn't even work with the latest version Visual Studio. You might want to get used to the idea of migrating to a new version control system.

Regarding CVS, you should not use that voluntarily. There are a number of reasons for this, but my main argument for its unsuitability is the lack of atomic commits. If one developer is committing while another is updating, the updating developer will see an inconsistent view of the repository (i.e. he'll see only part of what's being committed). This is clearly unacceptable. If that doesn't bother you, the fact that you can't move/rename files while preserving history will. Your first code refactoring will invalidate your project history.

OK, now to answer your question. No, git is not easier to use than other VCSs. It's unnecessarily difficult to learn, and that's a shame. Its branching and merging system supports some extremely productive workflows, but as far as I'm concerned, it's just a royal pain to learn.

I actually do use git, but it took me a long time to become comfortable with it. As far as I'm concerned, this is sad. It's just version control, for pete's sake. It shouldn't be so hard. And while the GUI tools are showing a lot of improvement, they are not there yet.

Most corporate projects would do best to select SVN for version control. It's extremely simple to learn (for those who don't already know it), and the GUI tools are excellent.

Most people who just want a place to stash their code and don't have a distributed team and don't really have branching and merging in their personal workflows, and I'm probably going to take a flaming for saying this, should also use SVN. I'm sorry, but git is just way to difficult to learn for your casual coder. It has something like 35 commands, and only about 10 of which are useful, but good luck finding them.

Re:What does Git, Got?

[assertation]

Thanks for the best answer to my question. I can't think of one time in my career where I ever got to choose my version control system. Both CVS and VSS were thrust upon me and in the place where I used VSS we didn't use Visual Studio so it was not a problem. VSS was also refreshing after CVS.

I will burn "SVN" into my brain in case I can influence a future job someday.

Deleting submodules

[Anonymous Coward]

If someone who hacks on Git is reading these posts, when are we going to have a single command to cleanly remove submodules as well as better support merges and rebases where submodules are changed or moved? Submodules are extremely awesome and I love the feature but doing anything more than adding them is a PITA.

Small code repositories

[Nicolas MONNET]

Such as the Linux kernel.

You're quite the comedian!

Mercurial for the Win

[cowwoc2001]

Mercurial has 95% of Git's functionality and is far easier to use. The extra features are simply not worth the headache.

Git's Windows support is atrocious. The installation process is an easy indication of that. Mercurial is packed of "just works" moments.

With Git, you can have better revision numbers

[prlawrence]

Whoever does the merging into your "master" repository has the ability to make it look however they want. If your devs really dislike SHA1s, then request that the master repo start employing tags. It's not hard; after the repo admin merges in new code, he can tag it according to whatever convention you like.

This is way better than arcane auto-generated version numbers. Will this small workflow change, you can have "meaningful" version numbers.

My favorite thing about Git is this: it is possible to make an extremely consumer friendly code repository. As "master" repo admin, you have the power to reorder, tag, squash, fast-forward, not fast-forward, whatever, until everything is just right. Then you can push to the master repo and listen to the oohs and ahhs as your devs (and later, your maintenance programmers) easily grok the gitk graph.

Re:With Git, you can have better revision numbers

[euroq]

Interestingly enough, this is pretty much what we've setup. :) The build system tags commits.

One thing that another user has pointed out to me about Bazaar is that Git's branches aren't inherently objects, just commits. When creating a branch in Bazaar the branch itself has a name/label. When groking the git graph, unless a developer properly tagged those branches, it is slightly more cumbersome to follow what and more importantly why the graph looks the way it does.

You apply sound engineering practice

[warrax_666]

and avoid breaking APIs willy-nilly. Instead you: provide the new API and deprecated the old in version n and remove the old API in version n+1 (or +2, or whatever).

If you have such a huge system (12 modules each of which is apparently too big for git), it's a very worrying sign that you're breaking the inter-module API often -- it probably means the modules aren't actually modular.

I love SVN

[jonahbron]

I love SVN, it works great, and the central repository model works great in almost every situation. But, recently, I've began using Git for my own projects because I dual-boot Windows and Linux. Allow me to explain.

With SVN, I have to maintain two different working copy trees: one for Windows, and one for Linux. This is because since they have different file addressing styles, they reference the central repository differently. So I can't just use the same working copy on both.

But Git fixes this problem by not caring where it is or where anything else is (unless you set up an origin, of course).

Another thing I like about git is that's it's practically impossible to break a project tree, as opposed to SVN where it's very easy. Your tree is completely clean except for a .git file at the very top. Though one thing I dis-like about it is the fact that I can't extract just a small part of a repository.

Not the git I was looking for...

[Anonymous Coward]

How disappointing... I thought this would be about Obama's election.

No metadata?

[Archwyrm]

Commit messages are metadata and you can put whatever you want in there. But if you are looking for something more structured: git notes. Probably the most important metadata that git saves though are merge commits. It is extremely useful to know the development history of a merged branch.

Most of the other things you list are merely different design decisions.

Major Git Problem: Limited Support for Windows

[misterjava1]

We were evaluating a source control system for my company, and we would have probably chosen Git but the sole major complaint was its limited support for Windows. When Windows users go to install Git on the main web site and are told that it's a beta version, it makes them feel like second class citizens in the Git world. Given that 80% of the desktop market is Windows, if I were on the Git development team and I were interested in attracting more users, I would definitely make Windows support a top priority.

Re:Git could use revision numbers... Not!

[Anonymous Coward]

Torvalds covered this issue in his google talk video about git. There's is no way this numbering scheme makes sense with git. Take a look at git rebase and git cherry pick to quickly see why your numbering scheme is not appropriate. With the ability to reorder commit history at will there's just no room for CVS like numbering schemes.

If you're not familiar with git, I urge you to take a look at Torvarld's talk on git.

Make sense

[Anonymous Coward]

Something that is overly complicated and not quite "right" is the product of choice for the Open Source community. Typifies 99% of all open source projects.

Git is popular because SVN is so bad.

[bored]

SVN was promised as the solution to everyone CVS woes. In the end it solved one or two problems and created a half dozen new ones more severe than anything wrong with CVS. At least, with CVS, when the crap hit the fan you fired up your favorite text editor and fixed the repository.

Git on the other-hand, when managed properly, doesn't seem to push people into corners that are extremely difficult to recover from.

Re:Git could use revision numbers... Not!

[euroq]

As I stated in the OP, this would ONLY work with a centralized repository setup, not a distributed one. The Linux kernel wouldn't make much sense with revision numbers. What I was thinking was that you could assign a repository to be flagged as the master, since in my experience I have worked exclusively with repositories that actually have a "master" repository.

And as I rebase and cherry pick all the time, I figure it would really hurt revision numbers, but other DVCSes seem to have tackled this problem. I don't know how, and I haven't thought it through enough. Personally, I think it would be fine for me to say "10th revision since this tag" and since the commit history could change, the revision numbers could change because it could become the "15th revision since this tag". The SHA would remain the same as the revision changed. And remember: this is only a people problem I'm trying to solve (communication, inherit description of the commit without looking up the SHA, etc.) Also, other posters have helpfully pointed out to me git describe, which I think I'll take a look at and start using.

Best Way to Learn Git?

[bill_mcgonigle]

Anybody have recommendations for the best way to learn Git?

And before you say, "just install it and use it", which I will, I'd like to learn from others' insights and mistakes, be it a book, web tutorial, class, etc. to save some time in the learning process.

Re:Best Way to Learn Git?

[alnicodon]

Just to get in the mood for it, first you have to read that lengthy introduction to git-svn for Subversion/SVK users and deserters. You're so not expected to read that page through to its end at the first attempt, so instead you're expected to refer to it again sometimes after your first hand-on experience. Here goes:

cd my_unversioned_project
git init .
git add .
git commit -m "initial import"

# hack, hack

git add modified_file_1 modified_file_2 added_file
# (at this stage, be sure to know what the "index" is)
git commit

and work that way locally for a while, venturing into branching (remember: git is about having plenty of small, not so short-lived, feature branches) and then merging until all that you see in the gitk --all and git ui GUIs make sense to you. Or, why not, cloning your repo/directory, and pushing from the clone to its "master".

Overall at this stage, the github usage docs and getting started are your friend. After this learning phase, stackoverflow will come in handy :)

Last, don't be too afraid to try things on working copy with clean status, since git commands only affects the .git repository in an append-only fashion, you'll be able to revert on every command that turned awful:

git reset --hard HEAD@{1}

will take you to the previously recorded state of your repository. Just look into git reflog for past things not necessarily in "gitk --all".

Short, only one links, but hope this will help.

Hal.

Re:Best Way to Learn Git?

[bill_mcgonigle]

Thanks, Hal! Much appreciated.

Re:Best Way to Learn Git?

[bryanbuckley]

These sites helped me a bit when I first started using git. The best way is to just start using it and set a goal to use a feature you just read about if you think it applies to your situation. I think the point of good-enough use of git is successfully operating like below, being able to use interactive rebases successfully and to know what command to use for the job (merge, rebase, cherry pick):
http://gitguru.com/2009/02/18/branching-strategies-overview/
http://nvie.com/posts/a-successful-git-branching-model/
http://stackoverflow.com/questions/2428722/git-branch-strategy-for-small-dev-team

Re:Best Way to Learn Git?

[badkarmadayaccount]

The website has a killer cheat sheet.