Blakeyxkcd and the years and years of struggling with broken software that just so happens to use git
-
How about reading the fucking thread and not wasting my time?
I've spelled-out EXACTLY what my concerns are, you just are an illiterate jackal who can't read.
-
I can read, I just can't discern between frontend and backend because with git there's almost no distinction. If you don't want to explain, I understand - I was just curious.
-
Money isn't the only motivation: wouldn't it be amazing if your open source project built itself? Making it more accessible and usable encourages people to use it, and making it easier to contribute means that more people will contribute when they otherwise wouldn't bother.
It depends on the project. I think popular adoption is the absolute last thing people who regularly use vim and emacs would like to happen. What's the biggest complaint about vim? Cryptic key sequences. But removing that would make it no longer vim. And why spend the resources on that when we already have notepad++?
-
Completely false. Git was designed by and for Linux kernel developers, who would be familiar with the command line.
They were familiar with the command line of a program that didn't exist yet?
did you seriously just argue both sides of the same dispute?
No he didn't. "Linus Torvalds made it." isn't an argument FOR something. Leaving snark aside, appeals to authority aren't arguments at all.Would a better front end solve all your issues?
If you made a front-end that hooked up to VS and behaved exactly like TFS, so he didn't have to know it's Git working underneath, he probably wouldn't mind it. At which point he'd point out he already has TFS, so why bother?I think popular adoption is the absolute last thing people who regularly use vim and emacs would like to happen.
After all, if everyone could use the software, what would they feel smugly superior about?
-
I wouldn't expect someone like Torvalds to succeed at creating usable software, but it'd be nice if he DIDN'T GO OUT OF HIS WAY TO MAKE IT AS UNFRIENDLY AS POSSIBLE (which I'm convinced is what happened with Git.)
Git is plenty friendly - to Linux kernel developers. Are their preferences invalid just because they're not the same as yours?
Filed under: rhetorical question
-
@antiquarian said:
Completely false. Git was designed by and for Linux kernel developers, who would be familiar with the command line.
They were familiar with the command line of a program that didn't exist yet?
Wat?
-
They were familiar with the command line of a program that didn't exist yet?
I'd rephrase, but I don't think it would help. Your mind seems to be thoroughly made up on this issue, as witnessed by:
After all, if everyone could use the software, what would they feel smugly superior about?
As if that is the only possible reason to prefer using emacs or vim.
Wat?
He is technically correct; the best kind of correct.
-
Git is plenty friendly - to Linux kernel developers.
They're used to Linus abusing them when they work on the kernel. With Git they can continue to feel abused when working on every other project.
Wat?
"Familiar with the command line" is something that doesn't exist. It's saying "they're used to typing things into a terminal and having things happen", which isn't a very complex concept to get familiar with. Learning to use a program with the command line is a new process for each program, no matter how many other cli programs you are familiar with, because the arguments for each program are unique to that program.There's no horizontal transfer of experience between command line programs the way there is with a gui, where for example once you've seen one scroll bar, you know what a scroll bar means in every other graphical interface program.
-
"Familiar with the command line" is something that doesn't exist
OK. You're wrong, but I understand what you were saying.
He is technically correct; the best kind of correct.
I'm not convinced.
-
where for example once you've seen one scroll bar, you know what a scroll bar means in every other graphical interface program.
Yes, like Discours-- oh wait. Shit.
-
So, anyway, I kind of like git!
I started using it in its offline capacity more.
When I'm playing around with a throwaway project, I just type two commands and I have a localized undo system. No need to mess with a public server or anything.
Neato!
-
The answer is: BECAUSE [G]IT IS BAD SOFTWARE WHAAAARGARBL.
Don't you ever get tired of tilting at this particular windmill?
(Note I'm not taking a position on git here either way, just curious.)
-
I'm always tired of everything, all of the time. So, so, tired.
-
A Git repo gets into a strange state you can't figure out and you end up having to re-pull a fresh copy to fix it
It happens a lot when I use "git svn". My work uses a SVN repository, and the most practical way I found to transfer my changes to and from the virtual machines I need to compile my projects without spreading my VPN and SVN private keys inside these VMs was having local GIT repositories and using git push/pull between the VMs and my computer which has the git-svn branch. I'm sure you would love this setup
-
I'm always tired of everything, all of the time. So, so, tired.
You're like that song
Three Days Grace - I Am Machine (Lyric) – 03:26
— ThreeDaysGraceVEVO
-
So, so, tired.
Why the hell does Youtube not have that Lethal Weapon "too old for this shit" bit from How I Met Your Mother?
You're not old enough to be too old for this shit!
-
Evil Bee Menomena – 04:21
— zindabadaOh to be a machine. Oh to be wanted. To be useful.
This music video is perhaps the most amazing adaptation of An Occurrence at Owl Creek Bridge ever made.
-
-
I love that video! And song.
-
GIT HAS BEEN AROUND SINCE 2005 WHY ISN'T THERE ONE NOW!
Why doesn't this bother you!?
"Yes sir! I love shitty software! Give me some more sir!"
I insist you take a look at GitExtensions if for some reason you have to use Git. The window decorations things were probably disabled just to keep it compatible with Mono and run on Linux. It's interface is much better than your typical opensource app.
-
If it's that time of the year where we're shilling for Git GUIs I would like to add git cola. Sure, it can still beweird, occasionally broken on Windows and requires Python, but at least you don't have to be a genius to use it as it looks modern (by Windows 7 standards, that is).
-
IIRC I didn't like it for viewing history
I installed all git gui I could found in ubuntu repository, and I wouldn't recommend any of them. I stopped searching when I found gitextensions. I didnt look into other windows only GUI.
-
Did you suddenly think I'd somehow lost like 45 IQ points and also all of my long-term memory and forget that? Did you think I'd go, "oh! Git Amend! Of course! The solution to my problem is simple!"
I think you actually lose 45 points every time you rant.Praising the fucking LOCKS?
I've been using Visual Source Safe back in 2004. The locks were the most, ever, annoying thing there ever was to it. They actually defeated the whole point of the teamwork.
I wish that whoever is still favoring the idea burns in fire. Or eats shit and dies while being gangbanged by angry grizzlies. I still have PTSD from the locks.
Blakey, JUST GO FUCK YOURSELF OR SOMETHING
-
I've been using Visual Source Safe back in 2004. The locks were the most, ever, annoying thing there ever was to it. They actually defeated the whole point of the teamwork.
They haven't been required in decades. Good time poddin'. "I don't know why you people want good ABS brakes on your 2015 4x4! Why, I used to drive a Conestoga wagon and the brakes on it were really awful! The horses hated them."
I wish that whoever is still favoring the idea burns in fire. Or eats shit and dies while being gangbanged by angry grizzlies. I still have PTSD from the locks.
I'm not asking for the tool to FORCE you to lock files, but having the OPTION would be fucking nice. You dumb fuck.
Blakey, JUST GO FUCK YOURSELF OR SOMETHING
Whoa, how'd you know I was doing something!?
-
@blakeyrat said:
Because Git moronically overwrites your source files during merge conflicts, then fails to check whether the merges are resolved before continuing. How the fuck do you tab in this paragraph to match the bullet list it's a part of? Why is Markdown so fucking awful? This Markdown cheatsheet page says it's three spaces, but that sure as fuck doesn't work, and four spaces turns it into a preformatted pane thing. Fuck Discourse.
I love how you just went into another rant in the middle of a rant without warning, and then transitioned back to the original rant seamlessly. Rantception.
Yes. Quite nice.
i award one Discohorse
http://i.imgur.com/oIP9yj9.png
-
There have been many times where I wanted to make a simple contribution to an open source project and changed my mind when I found out how difficult it was.
Same here. My personal "favorite": Pulling the latest master of an open source project and finding out it's built using autotools. Why the fuck do people use insane build systems like that? Why the bloody hell would anyone want to test whether the user is running a broken compiler from the 70s on a long-dead Unix system before any build?
-
+1. Projects with a
CMakeLists.txtare the only ones that I don't have to spend hours building properly.
-
Still, they could easily separate the git CLI frontend from the library backend and maintain them separately. It would sure fix a lot of problems with the ecosystem.
libgit2 is there and fairly feature complete (including SSH transport) with bindings to all sane languages.
-
99% of my git usage is covered by magit under emacs. The rest involves falling back to the command line and google.
Yes, git is hard, and yes, its command line is unintuitive. But it does some things you simply can't do with other version control systems. The main problem with git is how it does merges, which can get you into a world of hurt. But that's the same with all version control systems, and also why you always merge on a file by file basis regardless of version control system.
@hifi says "git isn't hard, you're just stupid". I'd say "git is hard, tough luck you stupid cunt"
-
When I'm playing around with a throwaway project, I just type two commands and I have a localized undo system. No need to mess with a public server or anything.
You'd still be better off with mercurial.
-
You'd still be better off with mercurial.
Maybe, but honestly, I'm really not that big VCS aficionado to learn yet another system, when I can already use the system that is
- the most popular
- gets the job done
-
That's fair. Hg's commands are generally more similar to svn, and doesn't have ridiculous concepts like detatched heads. It just works a lot better.
I know that I should learn git just to round out my knowledge, but I haven't had a compelling reason.
-
That's fair. Hg's commands are generally more similar to svn, and doesn't have ridiculous concepts like detatched heads. It just works a lot better.
I know that I should learn git just to round out my knowledge, but I haven't had a compelling reason.
Wait, if you didn't learn git, how do you know "it just works a lot better"?
Not that it matters, of course. If hg does the job for you, keep using it.
Important thing to remember is that, as a software developer, messing with VCS isn't your primary goal. Crafting software is. VCS is just another tool there to help you, like your IDE or command line tools. The amount of both the positive hype and negative drama surrounding git is just ridiculous IMO.
It's just a little tool to track your code, people. If you spend more than 10 minutes a day messing with it, you're doing it wrong.
-
Wait, if you didn't learn git, how do you know "it just works a lot better"?
I meant that hg works a lot better than svn. From everything I've seen, hg seems easier to use and to stay out of trouble with than git. I think that there are some things that git can do that hg doesn't, though that's less true today than it used to be. Honestly, I haven't kept up with hg's new features, so I couldn't really say.
Important thing to remember is that, as a software developer, messing with VCS isn't your primary goal. Crafting software is. VCS is just another tool there to help you, like your IDE or command line tools. The amount of both the positive hype and negative drama surrounding git is just ridiculous IMO.
I agree. But I understand that a lot of the negative drama is happening because people find themselves spending more than your 10 minute threshold on a regular basis.
-
I agree. But I understand that a lot of the negative drama is happening because people find themselves spending more than your 10 minute threshold on a regular basis.
Then
"people"
should spend a few hours going through one of those great tutorials linked above, instead of whining about it every day. If other people can use git productively,"people"
can learn to do it too.
-
ridiculous concepts like detatched heads
Detached heads are kind of a necessary feature for examining history. One great example is using binary search to find which commit introduced a bug: just check out commits and compile and test the code at that point in history. There's even a dedicated command for this:
git bisect
-
Detached heads are kind of a necessary feature for examining history
…and for rewriting history before pushing stuff to the server. Which is what we've been trying to teach blakey forever.
From everything I've seen, hg seems easier to use and to stay out of trouble with than git.
Basically, git is a tool for working with a DAG of commits (with a few pointers pointing to some of the nodes) and can do everything you might possibly want to do with a DAG. As long as you always remember that, git is actually pretty easy to understand.
-
doesn't have ridiculous concepts like detatched heads
Actually, I just found this, which might be helpful in understanding why a detached HEAD does not mean "broken state that you should always avoid".
Maybe the only thing the git is doing wrong is not forcing you to create a branch immediately when you commit with a detached head. Because I cannot think of a single reason why you would want to commit with a detached HEAD and not create a new branch.
-
Yes, git is hard, and yes, its command line is unintuitive. But it does some things you simply can't do with other version control systems.
Exactly. Some people would rather have flexibility than ease of initial use, but blakeyrat isn't respecting their feelings. He's microaggressing them.
-
Detached heads are kind of a necessary feature for examining history.
But implementation details of git make those things PITAs.
Basically, git is a tool for working with a DAG of commits (with a few pointers pointing to some of the nodes) and can do everything you might possibly want to do with a DAG. As long as you always remember that, git is actually pretty easy to understand.
There are just other tools that make it easier to work with a DAG of commits.
-
But implementation details of git make those things PITAs.
Not sure which implementation details you're talking about? I've only had to muck with the files in
.gitin older versions of git that had poor support for doing particular things.
-
Important thing to remember is that, as a software developer, messing with VCS isn't your primary goal
WHICH IS EXACTLY WHY GIT (and all other VCS) SHOULD BE AS EASY AS POSSIBLE TO USE!
That's exactly the problem here.
If the VCS is so fucking complicated it forces me to shove ALL the code out of my brain so I can fill up my brain with Git quirks instead, it's a bad VCS! It is no longer saving time, it's wasting it.
It's just a little tool to track your code, people. If you spend more than 10 minutes a day messing with it, you're doing it wrong.
By that logic, why would you use Git? The instant it fucks up (and it will), you've wasted 3 hours trying to get shit back on track.
(Unless you work like the guy in the XKCD comic and just delete your repo and start over, which is usually quicker.)
-
Not sure which implementation details you're talking about? I've only had to muck with the files in .git in older versions of git that had poor support for doing particular things.
I remember the first time I tried to do something with git, I managed to get a detached head and had to do something or other unintuitive (to me, a non-git user) to resolve something that didn't seem like it should have been a problem in the first place.
-
…and for rewriting history before pushing stuff to the server. Which is what we've been trying to teach blakey forever.
You people have such a warped way of looking at the world.
My (normal) brain: "Oh I forgot to put the ticket number on that commit's comment, I need to go back and add it."
ASDF brain: "I WANT TO REWRITE HISTORY! I BASICALLY AM GIT GOD! HISTORY IS MY SLAAAVE!"
The question isn't "do you want to rewrite history?" because the answer is, "duh, of course not." The question is: "why is Git designed so shitty that the only way to change a commit's comment is to rewrite history?"
Basically, git is a tool for working with a DAG of commits
NOBODY KNOWS WHAT THE FUCK A DAG IS!
If Git is reliant on these concepts, IT NEEDS TO TEACH THE USER THE CONCEPTS! It BLOWS MY MIND that anybody can defend the shittiness of this software. My mind is blown.
-
WHICH IS EXACTLY WHY GIT (and all other VCS) SHOULD BE AS EASY AS POSSIBLE TO USE!
That's exactly the problem here.
If the VCS is so fucking complicated it forces me to shove ALL the code out of my brain so I can fill up my brain with Git quirks instead, it's a bad VCS! It is no longer saving time, it's wasting it.
True.
By that logic, why would you use Git? The instant it fucks up (and it will), you've wasted 3 hours trying to get shit back on track.
(Unless you work like the guy in the XKCD comic and just delete your repo and start over, which is usually quicker.)
That happened to me once, about a year ago. And I did pretty much the same thing as the XKCD stick figure. But the only other VCS I've used (SVN) had similar issues (and more), so that doesn't say much.
Anyway, since then, things have been smooth with git. Haven't had issues, so no reason to look at alternatives.
Are other people at your company satisfied with git? Do they also waste a lot of time wrestling with it?
-
NOBODY KNOWS WHAT THE FUCK A DAG IS!
I don't know what it is, but I do know what it does: it nabbits. As seen in the popular phrase "DAG: NABBIT!"
-
Maybe the only thing the git is doing wrong is not forcing you to create a branch immediately when you commit with a detached head. Because I cannot think of a single reason why you would want to commit with a detached HEAD and not create a new branch.
I'd say their mistake was not isolating implementation details from the user interface. They designed this system, exposed the basic commands you can give it, but didn't tie that to user goals and use cases. Which is why they thing it's ok to let you "commit with a detached HEAD". It's like using assembly, you have to chain a bunch of low level commands to achieve your actual goal, and if you mess up you are screwed.
Consider blakeyrat's situation. "I want to edit an old commit." For a git fan, that's "easy": You just rewind, amend what you want, then fast forward. Notice how the interface turns a single task into three commands. That's a shit interface. A good interface would ask you "what commit do you want to alter, and what do you want it to say?", and it would handle the rewind, amend and ff steps behind the scenes.
-
The problem is that what blakey wants to do is change history. Git tries to make this hard intentionally. Also, git has no concept of "unpushed" or "not on the server" - for all it knows it could be the server. That's the point of being distributed.
In this particular case I think git is designed correctly: dangerous things should be hard to do.
-
Or you could have a warning "if you do this, anyone that has a copy of this repo will have to force update". Instead of making it hard because "you know best", lay out the trade-offs so they understand them and let the user make an informed decision.
Wrong things should be hard, making dangerous things hard just makes them more dangerous because you add the possibility of error.
-
I meant to say "wrong" instead of "dangerous" because it's not dangerous at all (unless they are already on the server).
