🔥 The CLI/Git... it burns! It burns us... It freezes...
-
The only reason I'm a "job hopping hipster", you piece of human garbage, is because I was laid off 3 years ago. Fuck you.
Fuck off yourself. Maybe it was just rationalization, but you've talked about how people who stay at the same company for more than a few years are stagnating or something.
(Oh and the company I was laid off from? It had both TFS and Git servers, and the projects were stand-alone with a small team, so I was able to make that call. Fuck you twice for reminding me of that.)
Maybe if you guys used git they'd still be able to employ you.
-
I'm not so sure about that. Usually when people slap a GUI on some Unix command line program, it works fine until something unexpected happens, which can only be solved by functions that are simplified away in the GUI design. In my experience a good handbook for the command line tool is more useful than a GUI addon.
Which doesn't mean I'm a cli fanatic - none of the above applies for software which has been specifically designed as a GUI application.
-
Usually when people slap a GUI on some Unix command line program
No, this is exactly the problem with git.
CLI is not API.
CLI is not API.
CLI is not API.
CLI is not API.
CLI is not API.
CLI is not API.
CLI is not API.
CLI is not API.
CLI is not API.
CLI is not API.
CLI is not API.
CLI is not API.
CLI is not API.
-
Well, in Unix it often is. Which means that perhaps one should describe the Unix CLI as a programming environment rather than a user interface. But for a software developer that should not be the end of the world, I'd think.
-
-
Stop introducing something that has be talked about repetitively and is not complete.
-
My current work is as a systems analyst and database administrator. The only programs I write are SSIS packages, some SQL procs and queries, a few PowerShell scripts, and Cognos reports. However, one thing I have to do all the time in my job is learn new software and teach software to new users.
The first step in mastering new software is: Figuring out what the hell the software developer that wrote the damn thing was thinking when he wrote it. Or, more accurately, what he thought you'd be thinking when you're using his software. No decent software developer goes into a project without a plan and some idea of what the user would have to be thinking to get the job done. When you do that, you'll understand why you have to be on a certain screen or use a certain mode to get something done.
Consider the difference between Windows and Unix. In Windows, everything is an object. Objects have methods and properties, and when you move things around, everything has to be binary communication to maintain object integrity. But since everything understands that, it all works. In Unix, however, everything is plain text character streams or plain files. You don't need all those methods and properties, because you can just use the existing tools to munge text and get exactly what you need. You only deal with binary when you have no other choice (and when you can't convert to plain text). Both systems have their advantages, and some people prefer one over the other. Doesn't make either one better. The only way you can really screw up is by trying to use one mental framework in the wrong software framework. The two models are like oil and water. Hence: If you think Windows administration involes installing Cygwin, you're doing it wrong.
You ever watch one of those carpentry shows on public television? You know, the ones where some guy in a flannel shirt and jeans builds a $5,000 chifferobe out of $200 of mostly scrap lumber? You ever notice how many ways there are to join two pieces of wood? You've got nails, brads, screws, glue, bolts, dovetails, mortice and tenon, notch and biscuit, and so on? How about buying a screwdriver or a hammer. There's dozens of different models with different shapes. Is one of those tools objectively better than all the rest in all situations? Keeping in mind that "popular" is not "objective," and "objective" isn't even "objective" when personal preference, existing workflow, and situational appeal are all valid considerations.
The first thing you learn when teaching people is that everybody thinks differently. People who think different than you aren't idiots. They just don't look at the world the same way. That's great, because those other minds like to do things you think are miserable like being an office manager or payroll specialist. Just like there's a shocking number of ways you can write a sorting algorithm, there's a shocking number of ways that people think. Sometimes you'll get somebody who can't think the way the software developer expected them to think. They simply don't think the same way about things. This doesn't mean anybody is an idiot (developer or user). It just means that the user and the developer disagree on reality. That software is a bad match for that user. This is one of the reasons why giving users multiple methods of accomplishing the same task is a crucial factor for user-friendliness.
Not everybody likes a CLI. There's a reason that essentially no major piece of software intended for end users features the CLI as the primary means of use. Most people hate them. It should be neither shocking nor offensive that a user dislikes software if it's CLI only. Strictly speaking, at some point if git wants more users they're going to have to adopt something more diverse than a CLI. Being CLI-only will hold software back. Given that (last I knew) the Git devs seem to be adamantly against allowing users to do the same thing with more than one interface -- which smacks of One True Wayism to me -- that does begin to look like unfriendly design.
Don't get me wrong, I like Git, but that doesn't mean it's immune to criticism or has some perfect design philosophy and people shouldn't be attacked for calling them out on it. The only problem I have with Git is the Git userbase. Sure, most users are like, "Yeah, Git's alright. It works pretty well. At least it's not CVS or VSS." However, for whatever reason, some open source projects attract zealots. The problem with zealots is that they're close minded. They tie their self worth to the percpetion of their favored project, so they allow no criticism and their primary goal when discussing the merits of the project is to shut down anybody who doesn't toe the line. It happened with Firefox before it hit 3.0. It happened with Ruby for the first few years it was out. It happened with Ubuntu. It happened with MongoDB before people realized NoSQL doesn't eliminate the problems of an RDBMS. I'm shocked it hasn't happened with atom.io yet... but maybe people are waiting for SublimeText to completely die. And, it happened with Git, which, realistically for most projects only offers very few feature improvements over SVN.
Blakeyrat doesn't like git. So what? He probably doesn't think the way that the Git devs do, so Git doesn't work for him. That doesn't mean Git is bad software. That doesn't mean blakeyrat is a bad user. It means that that particular package doesn't meet the needs of one particular user. Thankfully, there's a ton of other options for when software for when this sort of user/software mismatch happens. Ideally, he'd switch to Hg, SVN, or (god forbid) VSS. Unfortunately, blakeyrat doesn't have that choice because it's been made for him. That really sucks, and he can't fix it. Even if he had unlimited time and expertise and submitted patches to Git, it's unlikely they'd accept them because his mental framework doesn't match the one that Git uses. Patches he wants to Git don't match the assumptions that the Git developers have made. So blakeyrat's life sucks because one of his primary tools is one he hates. So why are people bitching at him for having an opinion they don't like about a piece of software?
Git isn't for him and that's OK.
-
Two things to keep in mind.
-
In Git, there are two types of command-line utilities. They are separated into "Plumbing" and "Porcelain". (I assume that's because Git deals with your shit). The Porcelain commands are UI-centric and can potentially change between versions. The Plumbing commands are the API, and they absolutely will not change functionality from one version to the next. An option may be added, but previous functionality will not change.
-
I would much rather have a GUI that supports 90% of operations I could need to do in a simple manner, than a GUI that supports 99% of operations I could need to do with far more buttons and options confusing the interface. Most Git GUIs support anywhere from 90% of operations needed to 95%. I tend to prefer the simpler ones. "git gui" which is built-in, is closer to the 90% mark. I rather like it that way. It's a bit ugly, but it does its job very well. Anything more complex, I can drop to the command line where needed, but since all the operations and concepts line up, I'm not going to confuse one interface by using another.
-
-
Anything more complex, I can drop to the command line where needed,
Unacceptable!!!
-
I would like to point to the thread about embroidery software and just how many buttons there are in even the cheapest systems. This is a case where the software is incredibly difficult to use because the problem domain is so large. Since the concepts that Git uses are not graphical, it is okay for 90% functionality to be displayed by a GUI. That way 90% of every-day use can be handled in the GUI, yet the UI can be kept simple.
For complex cases, where help may be needed, a chat-room or similar online-help system allows the transmittance of exact commands, versus "Click the revision filter button." "What does that look like?" "Like a funnel." "How does that make sense?" "I don't know, but somebody thought it was a good idea."
-
And, it happened with Git, which, realistically for most projects only offers very few feature improvements over SVN.
(Git has significantly FEWER features than SVN and, AFAICT, only one feature that SVN doesn't have. Git is slightly faster at many operations, but "faster" hardly counts as a "feature".)
But yes, thanks for your support.
-
Ideally, he'd switch to Hg, SVN, or (god forbid) VSS.
Does that solve so much? At work I use Hg because on Windows because it makes it easy to push to a shared network drive. But it is still just as much a command-line program as Git, and the GUI I am using for Hg (one of the major ones) is just as inadequate as any GUI for Unix tools. Just like with Git, when doing anything non-standard (like undoing the last commit, or tracking file renames, or undoing an edit, or whatever), Googling how to do it on the command line is quicker than figuring out why the GUI options aren't working properly. And I can barely imagine that it is any different for SVN.
-
HOLY WORDS BATMAN!
<f
-
HOLY WORDS BATMAN!
<f
Sorry, I was stuck in a meeting I didn't need to be in and couldn't participate in.
-
-
In Git, there are two types of command-line utilities. They are separated into "Plumbing" and "Porcelain". (I assume that's because Git deals with your shit). The Porcelain commands are UI-centric and can potentially change between versions. The Plumbing commands are the API, and they absolutely will not change functionality from one version to the next. An option may be added, but previous functionality will not change.
That's a stupid way of building software for about a hundred obvious reasons. If they thought that was a good idea, then-- to repeat my new catchphrase-- Git developers are incompetent.
I would much rather have a GUI that supports 90% of operations I could need to do in a simple manner, than a GUI that supports 99% of operations I could need to do with far more buttons and options confusing the interface.
You don't know anything about GUI design, do you. This is bordering on gibberish.
Most Git GUIs support anywhere from 90% of operations needed to 95%.
Haha wat? Most hover around 50%. SourceTree is maybe 85%.
The most usable Git client is GitHub for Desktop, and it doesn't even handle merge conflicts. I'm not even sure I'd call it 50%. Maybe 35%.
I tend to prefer the simpler ones. "git gui" which is built-in, is closer to the 90% mark.
This?
Nobody who worked on this has any fucking clue how to build GUIs. Hell the first goddamned thing it does when you hit "Open Existing Repository" (which is inexplicably a link and not a button-- even though it doesn't open a webpage) is show that awful Windows 95-era folder browser.
Does that solve so much? At work I use Hg because on Windows because it makes it easy to push to a shared network drive. But it is still just as much a command-line program as Git, and the GUI I am using for Hg (one of the major ones) is just as inadequate as any GUI for Unix tools. Just like with Git, when doing anything non-standard (like undoing the last commit, or tracking file renames, or undoing an edit, or whatever), Googling how to do it on the command line is quicker than figuring out why the GUI options aren't working properly. And I can barely imagine that it is any different for SVN.
This is an product line where ALL of the products suck. Even the one I kind of like, TFS, has a lot of fundamental UI errors.
It's like how the US has a whole bunch of competing cellphone carriers, and yet inexplicably they all suck about the same amount.
TortoiseSVN is actually one of the better options for source control in Windows. TortoiseGit is useless trash.
-
I can set up an SVN server from scratch in like 10 minutes. I've hardly ever had to look up documentation on it because for the most part, even the CLI is sane and generally intuitive. This tool does not get in the way of work.
Yet, every time I've touched Git I spent an inordinate amount of time trying to understand the tool. Stuff breaks and I don't know why, and when asking for help on the Internet the Git fanatics get all fired up and start name-calling instead of helping. Finally if I ever find a command that fixes everything, it's named something seemingly nonsensical and the best I can find online is "No we actually have no idea what that command does, but it seems to fix things."
The last time I touched Git, somehow my commits ended up attributed to a username I'd never seen before. Turned out something somewhere leaked and my commits were ignoring the username I supplied on the command line and instead using some other Git user somewhere else in the world who literally had nothing to do with the project.
That should not be possible. That is beyond even 
level of WTF. I don't trust Git for anything after that.I know everyone likes to pile on blakey just for fun, but I agree that Git is terrible software and should not be used anywhere. Problem is it somehow conjures up this obscene fanaticism and people refuse to acknowledge that there are far better tools out there for source control. It's like the Apple Reality Distortion Field multiplied by the DiscoDev attitude.
For the record, SVN is far from perfect. But by comparison I only spend maybe 5% of my development time jacking around with SVN, and most of that is because our SVN server version is ancient and the powers-that-be refuse to upgrade to 1.9, and the rest is because the TortoiseSVN developers are functionally retarded.
With Git it's more like 75% jacking with Git, 25% actual work. I wouldn't mind trying Mercurial because I've heard it's like a non-terrible version of Git but it hasn't come up yet on anything I do.
SVN might be a rusty old truck without a lot of speed, but it gets the job done. Git is more like a bus that is painted to look like a Ferrari, but the tires are all at right-angles to each other, there's a kitchen sink for a steering wheel, half the cylinders have no air intake because why would anyone need that?, the seats are upside-down, and you refuel the gas tank by ignoring the normal fuel cap and instead dispensing through the cigarette lighter. Yet the bus driver and everyone aboard continue to insist they're actually in a real-life Ferrari.
-
-
My current work is as a systems analyst and database administrator...
For some reason I read this post in the voice of Mike Rowe.
-
That's a stupid way of building software for about a hundred obvious reasons. If they thought that was a good idea, then-- to repeat my new catchphrase-- Git developers are incompetent.
I'd say that exposes the API to more languages than any other design choice could have. This way, you can write extensions in practically any language, including Shell Script (of any shell, not just bash).
You don't know anything about GUI design, do you. This is bordering on gibberish.
Maybe I've seen far too many shitty GUIs and never a good one. Even Mac Classic software, once I figured out how to use it, still wasn't that great. I remember trying to use some sort of data analysis software on OS8.6 that the teacher provided for science class, and finding a copy of Excel somewhere turned out to be loads easier. Given the pile of WTFs that is Excel 3.5, that's saying something.
Really, point me to something that is actually a good GUI, for anything. I'd really love to see what could be considered a good GUI.
Haha wat? Most hover around 50%. SourceTree is maybe 85%.
The most usable Git client is GitHub for Desktop, and it doesn't even handle merge conflicts. I'm not even sure I'd call it 50%. Maybe 35%.
GitHub for Desktop is the biggest pile of shit GUI I've ever seen for Git. It's certainly an exception to my "most" statement above. I would agree with your 35% functionality coverage estimate. It is pretty, but it is not functional. I really wish they'd just drop it, because it's almost completely worthless.This?
<picture/>
Nobody who worked on this has any fucking clue how to build GUIs. Hell the first goddamned thing it does when you hit "Open Existing Repository" (which is inexplicably a link and not a button-- even though it doesn't open a webpage) is show that awful Windows 95-era folder browser.Yes, that. Whenever I've clicked "Open Existing Repository", it has opened the same file browser as 90% of the rest of the software on my machine. I don't know what you're complaining about. If you've installed GitExtensions, you can also open it by right-clicking in a folder and saying "Open Git Gui" and it will open directly to the repository in that folder.
@blakeyrat said:This is an product line where ALL of the products suck. Even the one I kind of like, TFS, has a lot of fundamental UI errors.
Oh... I thought you liked TFS...
@blakeyrat said:It's like how the US has a whole bunch of competing cellphone carriers, and yet inexplicably they all suck about the same amount.
But they all suck in different ways. Source control seems very simliar to that - they all suck in different ways, and none of them are all around excellent at everything.
@blakeyrat said:TortoiseSVN is actually one of the better options for source control in Windows. TortoiseGit is useless trash.
I'll agree on TortoiseGit. That's why I have, on multiple occasions, recommended GitExtensions. If you want a more full-featured GUI than "git gui", it's the best mix I've found of function and non-overwhelming form.
-
@BaconBits said:
Ideally, he'd switch to Hg, SVN, or (god forbid) VSS.
Does that solve so much? At work I use Hg because on Windows because it makes it easy to push to a shared network drive. But it is still just as much a command-line program as Git, and the GUI I am using for Hg (one of the major ones) is just as inadequate as any GUI for Unix tools. Just like with Git, when doing anything non-standard (like undoing the last commit, or tracking file renames, or undoing an edit, or whatever), Googling how to do it on the command line is quicker than figuring out why the GUI options aren't working properly. And I can barely imagine that it is any different for SVN.Hm. In my experience with TortoiseSVN, the only time I've needed to drop to command line is to use
svnadminandsvndump, which isn't really something SVN client tool needs. TortoiseSVN lets you undo a commit with Merge, though, and as far as I'm aware you usesvn mergeto do the same thing at the command line.
-
Really, point me to something that is actually a good GUI, for anything. I'd really love to see what could be considered a good GUI.
For the specific example you cited (a GUI appearing simple, but exposing context-sensitive more advanced features as you dig into), the best example off the top of my head that you've likely used is newer versions of Excel with the ribbon interface.
Yes, that. Whenever I've clicked "Open Existing Repository", it has opened the same file browser as 90% of the rest of the software on my machine.
The problem is, that widget SUCKS in Windows. Anybody interested in making usable Windows software would avoid it like the plague.
And yes, that is Microsoft's fault, but it doesn't change the fact.
Oh... I thought you liked TFS...
I like it a hell of a lot more than I like Git, but it's still nowhere close to what I would call "quality software". The reason it really stands out is that all its competitors are SOMEHOW EVEN WORSE.
-
If that was at least made by the same people and shared code, maybe you would have a point.
-
Why is your new icon an ultrasound? Are you having a baby?
-
Nothing good has ever come from drinking Buckfast.
-
ftfy
-
No. No.
-
Skaven Ratling Gunners are dangerous, man. Don't make light of them.
-
Your icon is a shitty GUI. YOU KNOW NOTHING ABOUT GUI DESIGN.
-
If that was at least made by the same people and shared code, maybe you would have a point.
Do only reference implementations matter for anything?
-
I don't know
that isFortified wine with added caffeine.
It's concocted by English monks but mostly consumed in Scotland.
-
As I've said dozens of times, I already know Git.
Huh. Well maybe I have not read that every single time you wrote it.
-
Look, advice that requires using the CLI is useless to me because I won't use it.
Sometimes I'm a little surprised you haven't written a handful of stupid little GUI windows as a sort of mini-front-end to try to alleviate the pain. Or maybe you have but admitting it would detract from your rants here.
-
@boomzilla said:
I'm just pointing out what an ass he is.
Because I won't use a CLI?
No, I think it's because you're an ass, that he's pointing it out.
-
It's concocted by English monks but mostly consumed in Scotland.
By this, I hope you mean that there is one crazy old English monk that brews the stuff then runs off to Scotland to drink it.
-
If one user rants and raves about your software and refuses to even attempt to learn how to use it, and hundreds of thousands use it just fine, you can chalk up that one user to being fucking psychotic and move on.
If listening to SJWs has taught me anything it's that you should listen to the marginalized and othered etc., etc.
Also, look, what if all those hundreds of thousands are suffering from Stockholm Syndrome?
-
What would be the point?
I could only write code to do the normal basic stuff that works 100% of the time. There already are GUIs that do that, I'd be adding nothing that already exists.
The problem is when Git throws a little hissy-fit, and those are usually unsolveable and rely on me backing-up my changes, throwing away the busted repo, and re-syncing. Which is something I can also do through the existing GUI tools.
Now there might be a way for me to solve Git hissy-fits without tossing the repo, but they would in all likelihood:
- Require operations not supported by the GUI clients
- Take longer than just trashing it and starting over
So I don't bother.
To Git's credit I haven't seen "detached head" (the one that used to REALLY piss me off) in probably a solid year now.
-
I hope you mean that there is one crazy old English monk that brews the stuff then runs off to Scotland to drink it.
Me too. That'd be better than the actual truth.
More than one monk is required to keep up with Scottish consumption even if the monks didn't consume it themselves.
Paging @skotl
-
More than one monk is required to keep up with Scottish consumption even if the monks didn't consume it themselves.
*shudders*
-
To Git's credit I haven't seen "detached head" (the one that used to REALLY piss me off) in probably a solid year now.
You must have finally learned the standard workflow.
-
You must have finally learned the standard workflow.
I haven't changed my workflow one iota. It was caused by a bug in Git.
-
Which bug is that?
-
I don't know the number. Something about how Git handled (or failed to handle) file locking.
-
The problem is when Git throws a little hissy-fit, and those are usually unsolveable and rely on me backing-up my changes, throwing away the busted repo, and re-syncing.
I doubt what you consider 'unsolveable' is actually unsolvable.
-
I doubt what you consider 'unsolveable' is actually unsolvable.
Read the rest of my reply, numbnuts.
-
I doubt what you consider 'unsolveable' is actually unsolvable.
:scrolls_up.tga:
@blakeyrat said:Now there might be a way for me to solve Git hissy-fits without tossing the repo, but they would in all likelihood:1. Require operations not supported by the GUI clients2. Take longer than just trashing it and starting over
So I don't bother.
-
What would be the point?
[rest of post incorporated by reference]
I dunno--it was just an off-the-cuff idea. I've been fortunate enough to not to have to use git, so I didn't know if there was anything specific to you that you could make easier with a gui.
-
I can set up an SVN server from scratch in like 10 minutes.
git init --bareTotal time: 0.5s
Yet, every time I've touched Git I spent an inordinate amount of time trying to understand the tool.
You need a good tutorial then. Using Git without having read a good tutorial first can be challenging and frustrating.
The last time I touched Git, somehow my commits ended up attributed to a username I'd never seen before. Turned out something somewhere leaked and my commits were ignoring the username I supplied on the command line and instead using some other Git user somewhere else in the world who literally had nothing to do with the project.
That should not be possible.Seriously, I'd like a link to a bug report here, otherwise I'm not going to believe you. Git doesn't do magic to figure out your name, it literally only reads its configuration file and uses whatever is in there. You probably forgot to configure it and so it used
user@host.
-
Shhhh... I've got a headache.
Never again. Well, there's always tomorrow night, I suppose...
-
Git has significantly FEWER features than SVN
Lol, I thought you were serious until you bring svn in.
disagree.
