Well-reasoned anti-Git article
-
It's telling that git really caught on once Github came about... a giant centralized canonical location for git repositories.
-
It's telling that git really caught on once Github came about
If it wasn't for @accalia's Stockholm Syndrome, I'd have never started using Git myself; my own hobby projects are on Team Foundation Service
-
yeah i might migrate at somepoint..... bit... well git works so far....
-
I've only used it for Github, for single-developer projects, and I only interact with git via the Github for Windows app... because reading shit about git command-line confuses me.
-
It's telling that git really caught on once Github came about... a giant centralized canonical location for git repositories.
Correct; and that happened because SourceForge had been a stinking piece of foul shit for about 5-6 years before Git came along. Smart guys seeing an opportunity and grabbing it.
But GitHub's success has virtually nothing to do with Git. They could have just made a better SourceForge using Subversion and it'd have been just as successful. (Also, GitHub is pretty terrible in a lot of fundamental ways.)
If it wasn't for @accalia's Stockholm Syndrome, I'd have never started using Git myself; my own hobby projects are on Team Foundation Service
Microsoft's new TFS/Git cloud service is great, but alas, probably 3 years too late to get them any converts from GitHub.
-
Team Foundation Service
It's fun, but it's also free only for up to 5 users or so (if that's the thing I'm thinking about), and I remember having issues when we had an exactly 5-user team, then I added someone by the wrong e-mail and couldn't remove them so that they wouldn't count for the limit.
For personal projects, I use GitHub or TFS depending on the language mostly, for top-secret personal projects I use a git repo on my $5 droplet which also serves as a Netflix proxy/VPN.
-
yeah i might migrate at somepoint..... bit... well git works so far....
Is there a GitHub equivalent for Hg?
@Yamikuronue said:I've only used it for Github, for single-developer projects, and I only interact with git via the Github for Windows app... because reading shit about git command-line confuses me.
I've always used GUI tools for any and every VCS I've ever used, mainly because all the info is up front and easy to parse
-
-
I've had to use svn command-line, mostly due to some issues with svn for jenkins and having to drop to the shell to fix them.... but it's super straightforward. I've had just about no trouble with it.
-
It's fun, but it's also free only for up to 5 users or so (if that's the thing I'm thinking about),
They're competing with GitHub which is only free for open source projects, and Bitbucket which has similar restrictions for free accounts.
-
as far as i can tell just bitbucket
Assembla too, but I don't think there's a free version of that. But it is what my company uses for issue tracking/source control, so I'm already familiar with it.[s]Bitbucket has the advantage of supporting both Git and Hg though.[/s] Yeah, Assembla supports both too
-
They're competing with GitHub which is only free for open source projects, and Bitbucket which has similar restrictions for free accounts.
Do people even use GitHub for non-OSS projects? I mean, technically you can shell out for a private repo, but I've always thought GitHub was generally about OSS.
But yeah, I get it, and I get why they limit the number of users. I just found the (apparent, maybe it's just me) inability to remove users annoying.
-
Do people even use GitHub for non-OSS projects?
Yeah. Two of my previous employers have used paid GitHub accounts.
I mean, technically you can shell out for a private repo, but I've always thought GitHub was generally about OSS.
They're just as for-profit as SourceForge was. The difference is they smartly picked a subscription model instead of an advertising model.
-
Correct; and that happened because SourceForge had been a stinking piece of foul shit for about 5-6 years before Git came along. Smart guys seeing an opportunity and grabbing it.
That sounds vaguely familiar...
Correct; and that happened because forums had been a stinking piece of foul shit for about 5-6 years before Discourse came along. Smart guys seeing an opportunity and grabbing it.
-
Except it's not true in the case of Discourse.
I'll grant it in the case of StackOverflow-- QA sites were really, really shitty. That doesn't make SO good, that just makes it slightly better than the competition.
-
Imagine a bizarro world, in which WYSIWYG editors were never invented and people use Markdown for all text formatting purposes (inb4 "how would that world even survive without launching into insanity").
You only have to imagine it if you weren't around during the 80s. Of course, back then it was LaTeX, not Markdown, and I walked around college campus with an onion tied to my belt as that was the fashion at the time...
Filed under: I'd tell you to get off my lawn, but I live in an apartment.
-
QA sites were really, really shitty.
I don't know - there was the one that gave pretty good advice to aspiring transsexuals...
-
You only have to imagine it if you weren't around during the 80s. Of course, back then it was LaTeX, not Markdown, and I walked around college campus with an onion tied to my belt as that was the fashion at the time...
Yeah, I thought so, but didn't want to risk some pedantic dickweed barging in and saying "DUH YOU MORON THE FIRST WYSIWYG EDITOR WAS OBSCURE_PROGRAM_NOBODY_USED 1.0 WHICH PREDATES LATEX BY AT LEAST A WEEK".
-
"DUH YOU MORON THE FIRST WYSIWYG EDITOR WAS OBSCURE_PROGRAM_NOBODY_USED 1.0 WHICH PREDATES LATEX BY AT LEAST A WEEK".
Ah, so you've used FrameMaker too! (I've even gone so far as to use it over a 14400 baud modem. Never again! Just… never…)
-
I don't know - there was the one that gave pretty good advice to aspiring transsexuals...
expert-sexchange.com?
-
expert-sexchange.com?
Yes, that was the joke.
Filed under: appreciate the fucking subtlety once in a while, people
-
No, this is what.thedailywtf. Spelling-out jokes makes them funnier! So does being a pedantic dickweed! If someone makes a joke about a phone number getting a British person, the best response obviously is to point out that non-British people could potentially have the same phone number. HILARIOUS! You fucking humorless fucks!
-
Yes, that was the joke.
There was a related website called experts-exchange.com which offered a place where you could get programming questions answered if you signed up, or if you knew how the 'remove this HTML element' worked in your browser.
I think both sites probably originated from the same authors. The names were very similar.
-
Killing a joke once isn't enough, eh? You had to dig its carcass out, dress it up in pretty clothes, rape each of its orifices mercilessly, murder it again, and drive it back into the ground, eh?
-
I was just trying to establish which of the two sites we were talking about.
Somebody made a joke?
-
Yeah, I thought so, but didn't want to risk some pedantic dickweed barging in and saying "DUH YOU MORON THE FIRST WYSIWYG EDITOR WAS OBSCURE_PROGRAM_NOBODY_USED 1.0 WHICH PREDATES LATEX BY AT LEAST A WEEK".
So you really weren't around during the 80s. LaTeX wasn't the WYSIWYG editor, LaTeX was what people were using before FrameMaker was written. Except that people didn't try to use FrameMaker as if it were LaTeX, which kind of ruins your analogy. Sorry about that.
-
>Limbo is a term I use but VCS authors don’t. However, that’s because they tend to ignore a certain state that exists in all major VCSes (and give it no name because they tend to ignore it) despite the fact that this state seems to be the largest source of errors. I call this state limbo.
I had an coworker create what I only could count a 300+ level deep recursive loop of nested folders in SVN. Man were people confused when they went to checkout and a hour later their 2TB drives were full.
Never did figure out WTF happened. I had to nuke that repo from orbit on the server.
-
This "Limbo" is why I use a GUI for my day-to-day use of *VCS.
Whether it's the IDE integration or a standalone GUI, I get a nice graphical display showing what's in "limbo", "staged for commit" and "in the repo".
As a matter of fact, I really love git's "staged" state, which that author considered a source of errors.It's really useful where you've made a few minor fixes that want splitting into two or more commits, yet they're in the same file.
Stage line/stage hunk are possibly my two favourite context menu items - because I never had them before.
-
Sorry about that.
Yikes. At the right of channelling Blakey, "WHAT PART OF 'BIZARRO WORLD DO YOU NOT UNDERSTAND?!". It's bizarre, up is down, left is right, and people love Markdown.
Also, while it hasn't happened for LaTeX (though there probably are people who type LaTeX into Word, world is full of idiots of every variety), Excel has a pretty much similar backstory.
-
Does anyone remember or worked at a place where there was a job position "CVS administrator"? I worked in this places and this guys weren't procrastinating all day.
So a few years ago we had "experts" putting 40h/w maintaining a repo and now all this work is done by every single dev. It's not that Git/Hg/Bzr are harder than CVS, but that it's just another thing "every developer should know™". And this is bullshit, there's a limit of how many things a developer should know to get their job done, but everyday the list keeps growing. So no wonder people have a hard time figuring out about cheery-pick between bug hunting a framework, fixing some CSS position in IE and making SQL queries run faster without losing their minds.
-
I'm guessing pretty much everybody involved in this debate has never used TFS 2013, because it's really, really damned good.
Just upgraded to TFS 2013 from TFS 2008 at work about 4 months ago.
It. Is. Amazing.
Trying to learn GIT for a personal project.
I hate it.
-
Trying to learn GIT for a personal project.
after a long time of thinking here's my opinion:L
- If you know GIT and are okay with that use GIT
- Else: use mercurial
to that end i am working on migrating all my projects to mercurial
that's gonna be slow but i am working.
-
- If you know GIT and are okay with that use GIT
- Else: use mercurial
If your project is the kind that encourages patches from anybody, use a DVCS. Else: use a CVCS.
-
Trying to learn GIT for a personal project.
I hate it.
Most of my interaction with Git is through the Eclipse GUI where I can click options that sound (sometimes vaguely) like what I want to do, and that's what happens.
I've had to do it via CLI and.... well... Google is required.
-
Trying to learn GIT for a personal project.
I hate it.
GUI tools make the pain… not go away, but it does numb them a bit.
-
there's a limit of how many things a developer should know to get their job done, but everyday the list keeps growing
There's a lot less on that list than you think. For example, it doesn't include any specific programming language or tool, but rather concepts like revision histories and testing…
Most of my interaction with Git is through the Eclipse GUI where I can click options that sound (sometimes vaguely) like what I want to do, and that's what happens.
The best thing about the Eclipse GUI for git is the history browser, because it lets you see what the heck is actually going on, and it is even better than the Github history browser (as long as you're not needing to browse across multiple users' forked repos). The worst part is how you configure branches, especially with multiple upstream repositories (I have three for one of my projects); shit just breaks subtly.
-
The worst part is how you configure branches
I'm not sure I really understand why git handles its branches as something special and mysterious, rather than 'just another folder'. I suppose there's a reason for it, but I like the simplicity of the 'just another folder' model...
-
I'm not sure I really understand why git handles its branches as something special and mysterious, rather than 'just another folder'. I suppose there's a reason for it, but I like the simplicity of the 'just another folder' model...
They're not a folder, they're a configuration. Actually, git treats branches in two ways, as a history of configurations and as a labelling on a specific point in that history. The “history of configurations” is sane, but the way that the labelling works is just strange and still sometimes causes me grief.
The “everything is a folder” is SVN through and through, and it is odder than it appears to be at first because you can put branches inside branches.
Yes, that's stupid. Yes, I've seen that done far too much.
-
branches inside branches.
Yo dawg...
Yeah, I'm struggling to come up with a use case where a branch inside a branch is a useful or desirable thing to have. (You have a load of dev branches, and you want to merge them all into release branches simultaneously...?)
-
You have a load of dev branches, and you want to merge them all into release branches simultaneously...?
SVN merge? A year later, you might have resolved all the conflicts…
-
I'm struggling to come up with a use case where a branch inside a branch is a useful or desirable thing to have.
I have better things to do with my nerve cells.
-
SVN merge? A year later, you might have resolved all the conflicts…
NOREPRO. I've had more success merging svn than I have with git...
-
These clutter up our server because when I start investigating a bug on "develop" I don't yet know whether it'll require code changes or not-- after being bitten in the ass like 5 times over having to somehow port changes from "develop" to the bug branch (because Git throws a huge hissy-fit), I just pro-actively create the bug branch first now and switch to it even before doing any investigation. Then we end up with tons of leftover branches with no commits in them, when I then have to go in and manually clean-up. (ANOTHER WAY GIT SAVES ME SO MUCH TIME! BORING JANITORIAL WORK!)
Why, Why, Why, Why, WHY?!?!
The whole point in distributed is that you don't need to create the branch on server before you start to work. You create the branch on your side and when you find that you need changes on it, you push it on the server creating the corresponding branch there.
The only reason you even need to do that (in my experience) is to switch branches-- because Git is too fucking stupid/idiot/dumb to cope with switching branches with uncommitted changes, another misfeature that bites me in the ass almost every day.
You've apparently never been bitten by
svn updateorsvn switchending with conflicts and messing up your work. It did not happen often, but whenever it did, it was a huge pain. That's why git does not allow it.Git was designed by people who do switch branches a lot. I agree they totally failed to explain what is the supposed workflow is. But I am sure what you describe is not it.
The problem is that Git has no ability to work online. That's a feature virtually every other VCS has but is only a giant gaping void in Git.
There is no VCS in the world that would ever work “completely” online. In all of them the work in progress is local on the developer machine. Even in the most online ClearCase with dynamic view the data of the checked out files is still stored locally. The fact that DVCS split the check in operation to local commit and push that actually publishes the state changes absolutely nothing. You can't access someone else's work in progress when they are suddenly unavailable.
-
But "having a local repository" is not a difference between DVCSs and CVCSs. You can easily have a CVCS with local repo copies which get synchronized with the central server.
You can equally easily have a DVCS without local repo. The difference between centralized and distributed is that centralized needs a central authority for assigning branch and revision identifiers while distributed has no such authority.
The defining difference between the two is that in a DVCS, you're supposed to do a peer-to-peer patch exchange, instead of having a separate server which everyone consults. The local repos are just a side-effect of that.
You are not supposed to do peer-to-peer patch exchange. You can do it, which is side-effect of not needing the central server just as local repos are.
The reason for not having a central server is that it makes things simpler. In a sense of more orthogonal core concepts, better separation of concerns and higher flexibility. It does not mean that it's easier to understand; for many developers who were used to the centralized systems it is clearly pretty hard.
So to me, the whole concept of a DVCS is pretty much dead.
You can build a centralized on top of distributed one. The other way around it was tried too, see SVK, but it never worked really well exactly because the centralized system doesn't really support moving the data around.
The decision for distributed is more a matter of software design that happens to make some features possible, easier or more reliable and a handful of features (ok, I can only think about locking files that can't be easily merged) more difficult.
in a DVCS there's no central server at all, and the way people use Git is Doing It Wrong (or in this case, hacking it into something workable).
No. The way people use Git is Doing It RIGHT. Nobody says in git you should not have a central server. There is just no technical reason to have it. But because in most cases there are social/organizational reasons, you still have it. That's not doing anything wrong.
There is nothing superior on sharing patches in peer-to-peer fashion. It's an option that distributed systems give you. And the reason they do is that the underlying model happens to allow it.
-
But GitHub's success has virtually nothing to do with Git. They could have just made a better SourceForge using Subversion and it'd have been just as successful. (Also, GitHub is pretty terrible in a lot of fundamental ways.)
I tend to disagree. There was SVK, which allowed actually taking advantage of the version control system if you wanted to contribute to a project using subversion and didn't have permissions to the central repository, but it was ugly hack because the subversion model is unsuitable for the use-case. The distributed model made that a lot easier. It didn't have to be git—mercurial, bazaar, fossil or others would do too—but not subversion.
-
The whole point in distributed is that you don't need to create the branch on server before you start to work.
Except you do, because you have to create it from JIRA/Stash so it has the correct branch name and is linked to the correct JIRA ticket number. And there's no way to create a local-only branch from the server.
Git was designed by people who do switch branches a lot. I agree they totally failed to explain what is the supposed workflow is. But I am sure what you describe is not it.
I'd love to hear what I'm doing "wrong".
There is no VCS in the world that would ever work “completely” online.
There are, however, dickweeds in the world who are completely pedantic. Fuck off.
The reason for not having a central server is that it makes things simpler.
Hahaha, what?
It does not mean that it's easier to understand;
Oh, look, even you believe your own statement is bullshit. So Git is somehow simultaneously simpler and harder-to-understand. It exists in a quantum WTF state until you open the lid of the box and find out it killed your cat.
The decision for distributed is more a matter of software design that happens to make some features possible,
The problem is the now-possible features are ones nobody asked-for or wanted, but now everybody is stuck with the complexity. The complexity of the simplicity. Or whatever the fuck you were word-barfing earlier.
No. The way people use Git is Doing It RIGHT.
You just told me I was doing it wrong.
Nobody says in git you should not have a central server.
Except when my company uses Stash as a central Git server, you tell me I'm doing it wrong.
There is just no technical reason to have it.
File locking. We've already been over this a thousand times, you even mentioned it yourself. Your memory really sucks, buddy.
But because in most cases there are social/organizational reasons, you still have it. That's not doing anything wrong.
... unless you're Blakeyrat.
-
Except you do, because you have to create it from JIRA/Stash so it has the correct branch name and is linked to the correct JIRA ticket number. And there's no way to create a local-only branch from the server.
To be fair, that does sound like an organisational issue, not a Git issue; you'd probably have the same issue with Hg or TFS.
@blakeyrat said:So Git is somehow simultaneously simpler and harder-to-understand. It exists in a quantum WTF state until you open the lid of the box and find out it killed your octocat.
;)
-
Except you do, because you have to create it from JIRA/Stash so it has the correct branch name and is linked to the correct JIRA ticket number. And there's no way to create a local-only branch from the server.
You don't need a centralized system for issue tracking either; fossil proves this by demonstration. But your issue IDs then necessarily become hash codes, not simple human-readable numbers, because two clients have to be able to independently come up with the same unique ID when looking at the same content. (That's the core principle of how DVCSes really work.) You could keep a file that maps nice IDs to the ugly hashes, but then you've got to deal with merging in that file…
FWIW, I think that git ought to be the most beloved thing of Jeff ever, since it is so wonderful at Doing It Wrong, but in a way that lets you struggle on anyway. But there are other DVCSes that get it much more right.
-
-
Yes.
YesManagement decided we do.
They could just as easily decided otherwise. But then that would require intelligence, which management types aren't known for ;)
