Live data from Hacker News

Git Is Simpler Than You Think

nfarina.com

81–90 of 122 posts

Re: Git Is Simpler Than You Think

#81
post #77
post #45

Earlier quoted context omitted.

Technically speaking it doesn't "mess up" the revision history, it preserves it. Rebasing instead of merging creates a linear revision history, which is simpler and more similar to centralized version control, but at the cost of losing information about the actual path of development.

All true. Certainly nothing is "messed up". That said, reading through a bunch of fine-grained and uninformative merge commits when looking at a log is really annoying. Serious projects expect submissions to be in the form of clean patch sets that apply in series and "look like" an instantaneous change. No one cares about per-developer histories. If you look at the kernel history, for example, the only merge commits…

Right, because the kernel patches are emailed and never pushed to a public location. In essence, the "committers" of the kernel are the only ones who do rebases (either explicitly or implicitly).

Frankly, git was not designed for a lot of the use cases it's finding itself in. Medium sized agile teams (5-10 devs) with multiple people mucking around in the same files will be removing bullets from their feet repeatedly for a few weeks when first switching.... OR they will have an incomprensible tangle of branches and merge commits that no person will ever be able to figure out.

Re: Git Is Simpler Than You Think

#82
The sea parted for me when I caught Scott Chacon explaining git.

  http://www.youtube.com/watch?v=QF_OlomyKQQ
It really is better in so many ways and once you understand how it works, you may say, like me, "Ahh, YES!"

And, yeah, he warns you about rebase.

Re: Git Is Simpler Than You Think

#83
post #81
post #77

Earlier quoted context omitted.

All true. Certainly nothing is "messed up". That said, reading through a bunch of fine-grained and uninformative merge commits when looking at a log is really annoying. Serious projects expect submissions to be in the form of clean patch sets that apply in series and "look like" an instantaneous change. No one cares about per-developer histories. If you look at the kernel history, for example, the only merge commits…

Right, because the kernel patches are emailed and never pushed to a public location. In essence, the "committers" of the kernel are the only ones who do rebases (either explicitly or implicitly). Frankly, git was not designed for a lot of the use cases it's finding itself in. Medium sized agile teams (5-10 devs) with multiple people mucking around in the same files will be removing bullets from their feet repeatedly…

That may be overstating things. The incomprehensible tangle is really just an annoyance. Look at it with "git log --no-merges" and it looks exactly like the tangle you'd get with CVS or subversion: lots of independent unsequenced changes by different developers.

Git by default shows this stuff, which in the kernel's use case is useful data. But in this case it's just useless chaff, and an annoyance. But hardly a serious problem.

Re: Git Is Simpler Than You Think

#84
I made the executive decision to leave our comfy world of Versions because it seemed clear that Git was winning the Internet.

I ADORE git and can't imagine NOT using it now that I've switched, but the little sentence above packs a whole lotta lame in it.

Executive decision? Gross. There are good reasons for them, but not many. If you can't win your team over you probably don't have a good argument for the change... which brings me to the next problem I have with that sentence: winning the Internet? That's a great reason to look into something. Not a great reason to switch your team to it.

Also, no. It's not simpler. It's pretty much just as complicated as You think it is. It's actually kind of a big pain in the ass to start using git.. but boy is it worth it.

Re: Git Is Simpler Than You Think

#85
post #65

Earlier quoted context omitted.

You're being downvoted for not using an HN approved workflow. Your workflow is inconceivable and therefore wrong.

Maybe I'm just grouchy today, but what's inconceivable to me is why you'd write an Oh No The Hivemind comment on this topic of all things. Some workflows actually are suboptimal.

The people complaining about this particular workflow being suboptimal do not understand it, nor why it exists in the places it does. Sometimes when something looks stupid, it's because it is stupid. But sometimes it's because you don't understand what you're looking at.

Re: Git Is Simpler Than You Think

#86
post #73

Earlier quoted context omitted.

He didn't say the repo would be too huge for the server where the svn repo lives today. He said it would be too huge for the laptops. The binaries are already deduped, that's why they live in svn.

The OP made no mention of how large the SVN repo is, but rather speculated that the git equivalent would be "100s of GBs". Had the statement been: "Our SVN repo is alreay 100s of GBs in size" then yes you are not likely to want to stuff that onto a laptop but that was not the claim. The claim (without rationale) was that the git equivalent would be 100s of GBs which is similar but not at all the same. one assumse 1:1…

He speculated that the entire history (which I would say is equivalent to the SVN repo) is 100s of GBs. We are assuming a 1:1 svn repo to git repo ratio.

Mozilla's ratio would be relevant if they were storing something like the visual studio installer in their repo. They aren't, so it's not.

Re: Git Is Simpler Than You Think

#87
post #73

Earlier quoted context omitted.

He didn't say the repo would be too huge for the server where the svn repo lives today. He said it would be too huge for the laptops. The binaries are already deduped, that's why they live in svn.

The OP made no mention of how large the SVN repo is, but rather speculated that the git equivalent would be "100s of GBs". Had the statement been: "Our SVN repo is alreay 100s of GBs in size" then yes you are not likely to want to stuff that onto a laptop but that was not the claim. The claim (without rationale) was that the git equivalent would be 100s of GBs which is similar but not at all the same. one assumse 1:1…

The binaries (including debug symbols etc.) are the bulk of that size, and storing all revisions locally will almost certainly add up to non-trivial size for a laptop. Unless git has some kind of magic differencing algorithm specifically executable code and debug symbols, I don't really see a way it could work - that's my rationale.

Of course, such algorithms do exist - Google's Courgette - but I don't think git is using them (I have looked) and doubt they are tuned to e.g. Borland TDS/RSM/etc. symbols.

I have no idea how large the svn repository is - it's stored on a SAN and run on a dedicated server I only interact with via svn. It could be many terabytes for all I know; and of course, my team's project tree isn't the only thing in the full repository.

Re: Git Is Simpler Than You Think

#88
post #41

The whole "downloading history of the repository onto your machine" thing about git is what makes it unworkable where I work. A normal checkout from SVN is over 3GB in size just for our team's tree. There are a number of binaries that get pulled in and updated for various reasons (SDKs, platform-specific binaries) and they are versioned for repeatable and automatable builds across branches, all self-contained with mi…

But have you actually tried it? You might be surprised.

I might give it a bit of a go when I'm on-site in CA in a couple of weeks, rather than trying it over transatlantic VPN - though my MBA only has 256GB SSD, and it's 50/50 Windows 7 and OS X.

Still optimistic? :)

Re: Git Is Simpler Than You Think

#89
post #41

The whole "downloading history of the repository onto your machine" thing about git is what makes it unworkable where I work. A normal checkout from SVN is over 3GB in size just for our team's tree. There are a number of binaries that get pulled in and updated for various reasons (SDKs, platform-specific binaries) and they are versioned for repeatable and automatable builds across branches, all self-contained with mi…

git-clone --depth 1

Shallow clones are essentially read-only, they can't push nor be fetched from. Unless you're prepared to regress to emailing patches around, a shallow git clone is actually less useful than a svn checkout.

Re: Git Is Simpler Than You Think

#90
post #41

The whole "downloading history of the repository onto your machine" thing about git is what makes it unworkable where I work. A normal checkout from SVN is over 3GB in size just for our team's tree. There are a number of binaries that get pulled in and updated for various reasons (SDKs, platform-specific binaries) and they are versioned for repeatable and automatable builds across branches, all self-contained with mi…

Git repositories are quite a bit smaller than svn's[1], but hundreds of GB is pretty huge.

[1] http://www.contextualdevelopment.com/logbook/git/large-proje...

Post reply on HN