More complaining about git
-
Dear git: STOP CHANGING DEFAULT BEHAVIOUR!
My struggles with git have been well documented. One thing I didn’t touch on is its tendency to suddenly change the behaviour of core commands from release to release. I’ve got used, ov…
I thought you guys might like to see a better class of gitplaining from someone who has actually read documentation.
-
Sorry, but this guy is full of shit. So what, every early decision you make must be set in stone and never changed?
These deprecation messages are clear, and offer you a clear path to never seeing them again, either by accepting new defaults or keeping the old ones. One alias or config change and you're done.
Git has its problems, but this is an example of API moving forward done right.
-
He's not talking about the API moving forward, he's complaining about the UI changing. Despite what shitty Linux programmers think, CLI programs are not APIs. They're UIs. If other programs are using user interfaces, those programs are doing it wrong.
-
I would argue they are both. There are definitely GUIs that use text-based interface to communicate with git. So for them, it's API.
Either way, you can't expect interface to remain locked forever. And this is the correct way to do the change.
-
I would argue they are both. There are definitely GUIs that use text-based interface to communicate with git. So for them, it's API.
Those are wrong and stupid and written by dumbasses. Incidentally, a lot of open source software follows this pattern.
Either way, you can't expect interface to remain locked forever.
You can expect design work to be front-loaded so changes like these would have been made before release.
-
Either way, you can't expect interface to remain locked forever. And this is the correct way to do the change.
Linus makes a special effort to complain about SubVersion, but at least SubVersion acknowledges that a lot of programs consume the text output of svn.exe and they go to great lengths to keep the output consistent.
-
Those are wrong and stupid and written by dumbasses.
Not necessarily. It allows you to automate bla bla powershell bla bla...
We both already heard all the arguments pro and con. Let's leave it at that.You can expect design work to be front-loaded so changes like these would have been made before release.
Git was already released. These are breaking changes for version 2.0.
-
Linus makes a special effort to complain about SubVersion, but at least SubVersion acknowledges that a lot of programs consume the text output of svn.exe and they go to great lengths to keep the output consistent.
But SVN is already the stodgy uncool choice and they don't have a rockstar at the helm. So they have to be nice.
-
Not necessarily. It allows you to automate bla bla powershell bla bla...
PowerShell uses the API directly. That's exactly what makes it better than all previous attempts at decent CLIs.
We both already heard all the arguments pro and con. Let's leave it at that.
There are no pro arguments. The only possible argument for is, "we've always done it that way".
Git was already released. These are breaking changes for version 2.0.
Right; but my point was these changes would not be necessary if they'd spent more time designing the product up-front.
-
PowerShell uses the API directly. That's exactly what makes it better than all previous attempts at decent CLIs.
PowerShell is a fucking train wreck. The sheer number of commands and arguments that it takes is borderline preposterous. It really should be broken apart in to subsections. This is why Server Core will never be viable without a management headend. No one could possibly ever use it as their sole install.
But, where it is a shit CLI, it is a pretty decent API. But shit, we are arguing about semantics here.
-
Right; but my point was these changes would not be necessary if they'd spent more time designing the product up-front.
So... 1.0 is always the end of evolution? You don't get to make changes, ever? There was no Start button in Windows 1.0, so we don't get to have it in Windows 95?
-
So... 1.0 is always the end of evolution? You don't get to make changes, ever?
You don't get to make API changes, ever.
That's exactly why it's folly to use a UI as a API, like idiot dumbface stupid morons do. Because once you're using a UI as an API, that UI can never change or evolve again, ever.
-
@Intercourse said:
But, where it is a shit CLI, it is a pretty decent API. But shit, we are arguing about semantics here.
Are all CLIs just bad APIs and/or are all APIs just bad UIs?
-
@Intercourse said:
The sheer number of commands and arguments that it takes is borderline preposterous.
Huh? Aside from being a bit verbose in command names (that "verb-noun" rule is kinda stupid), you only need a few of those commands - certainly not more than you'd need in any other shell. And you always have an escape hatch in .NET objects, if you so please.
A big plus of PS is that it at least tries to be consistent, instead of being a bunch of different programs with one-letter parameters which never mean the same thing.
-
@Intercourse said:
PowerShell is a fucking train wreck. The sheer number of commands and arguments that it takes is borderline preposterous. It really should be broken apart in to subsections.
That's a horrible argument. Microsoft made PowerShell extensible and a ton of Microsoft teams and third parties added a ton of functionality. That's nothing but a good thing. Now that the ISE has intellisense (and the pure CLI has tab completion) and there is a clear naming convention to follow, there's no excuse for getting lost in the forest of commands.
-
Are all CLIs just bad APIs and/or are all APIs just bad UIs?
Neither, however some don't build an API for their tool that they expect others to hook up to. In those cases you have to plug into the UI due to a lack of API, which is unfortunate as it means either the UI is locked or your thingy is going to break later but that is the cost of hooking up to something that lacks an API.
-
In those cases you have to plug into the UI do to a lack of API
Which would obviously be a pretty retarded thing to do with a windowed app, but somehow for CLI it's fine. Go figure.
On the other hand, that mentality also means that people will generally try to keep their CLI consistent... until they don't.
Filed under: words from a guy whose printer account management system for the company involved banging out HTTP requests
-
Are all CLIs just bad APIs and/or are all APIs just bad UIs?
Wait, what did I just say?
Need more caffeine, maybe a drink, and definitely for people to stop interrupting me. I acknowledge that my reply was mostly akin to the Billy Madison debate.
https://www.youtube.com/watch?v=wKjxFJfcrcA
I know I had a good point...somewhere. I stand by one thing though, I personally hate PowerShell. Maybe I am just getting old and crotchety?
You don't get to make API changes, ever.
I will absolutely disagree with this though. You should plan your API so that hopefully you do not have to ever change it. You should not change it often, and you should have a damn good reason when you do, but to say that you should never change it, ever, is just fucking stupid.
-
@Intercourse said:
You should plan your API so that hopefully you do not have to ever change it.
*cough* Win32 *cough*
-
@Intercourse said:
You should not change it often, and you should have a damn good reason when you do, but to say that you should never change it, ever, is just fucking stupid.
Depends what kind of change you mean. A change that adds a new call? OK. A change on how something is called or to remove a call? No (if you are removing due to security issues, patch the bug but leave the API alone).
-
Which would obviously be a pretty retarded thing to do with a windowed app, but somehow for CLI it's fine.
Been there, done that. There's a difference between a user saying "Crap, now I have to automate this thing, I hope it doesn't blow up in my face." and an app developer saying "We have two APIs, our core API and the CLI. BTW, we change the CLI all the time - good luck.".blakerat's right that APIs shouldn't be changed. They should be fully supported in their current form until they are retired. See the IOS API for an example of a company that retires APIs too quickly - if your APIs don't last a lot longer than that, you are doing it wrong.
-
*cough* Win32 *cough*
Ummmm... no one goes to greater lengths to provide backward compatibility for their APIs. Microsoft often puts in special work arounds so that horrible programs continue to function properly. They'll even bake a bug in as a backwards compatibility behavior if it benefits their customers to do so.
-
That's exactly why it's folly to use a UI as a API, like idiot dumbface stupid morons do. Because once you're using a UI as an API, that UI can never change or evolve again, ever.
Ok, I can see the logic. Three points:
-
This isn't a web API, where you are tied to a single online application that must remain consistent. If your app is targeting git v1.x and v2.x breaks your shit, you can still bundle git 1.x and carry on. You're not completely screwed.
-
There's nothing preventing you from adding "1.x" mode switch that brings back the old API/GUI. Not saying that's what git should do, just that you can use some kind of versioning strategy to ease the change.
-
API-s can and should change. It's not as big of a deal as you're making it to be.
But I can see how GUI development can be impeded by API concerns. Once again, it's a tradeoff. Simple things are sometimes harder than in a human-only UI, but by having this whole programibility layer, you can accomplish complex things that you couldn't otherwise.
-
-
Ummmm... no one goes to greater lengths to provide backward compatibility for their APIs.
That's my point exactly. On one hand, you don't break existing programs, which is nice and cool. On the other, you end up with remnants of the jolly old times where you had to worry about near and far pointers.
And of course, since it's in your documented API, some intern is bound to Google for a solution, see one of those functions, ignore the big red warnings saying "DUDE DON'T USE THAT IT'S OLDER THAN YOU AND WE WROTE IT HIGH ON DRUGS", and happily include it in a billion-dollar piece of software.
Sometimes I wonder how folks like Raymond Chen still manage to preserve their sanity. Must be the knitting.
-
@Intercourse said:
I will absolutely disagree with this though. You should plan your API so that hopefully you do not have to ever change it. You should not change it often, and you should have a damn good reason when you do, but to say that you should never change it, ever, is just fucking stupid.
The only reason to change an API is:
- You find a security exploit
- You can't possibly fix it without changing the API
Note that you can (and probably should) version your API, or individual API calls. So you can write a new version of the API. But the old version should continue working as well.
Microsoft's problem, since I see people bitching about Win32, is that people don't use their API, but dig around in the implementation details and use those directly. That's what makes Win32 a mess more than anything else: developers who ignore the API contract and just do whatever.
Remember, it wasn't until (relatively) recently that Microsoft had a clean way of shimming compat. fixes without fucking every other app in the universe with them.
-
If your app is targeting git v1.x and v2.x breaks your shit, you can still bundle git 1.x and carry on. You're not completely screwed.
Until a security bug is found in Git 1.x, then you're fucked.
But I can see how GUI development can be impeded by API concerns. Once again, it's a tradeoff. Simple things are sometimes harder than in a human-only UI, but by having this whole programibility layer, you can accomplish complex things that you couldn't otherwise.
Git's CLI commands are a UI also, that's fundamental to the point I'm making.
-
Remember, it wasn't until (relatively) recently that Microsoft had a clean way of shimming compat. fixes without fucking every other app in the universe with them.
Huh? I remember that even Win 3.1 had a compatibility flags section for each program. Unless we're using a very different definitions of "recently".
Clean - maybe not, but I've never seen my compat settings mess with any other program. Granted, I mostly just screw it all and use a VM these days.
-
Git's CLI commands are a UI also, that's fundamental to the point I'm making.
I got you, my point is, that can have its good sides too.
Until a security bug is found in Git 1.x, then you're fucked.
That's an interim solution. You have to move on at some point.
It sure would be lovely if that Win 3.11 app still worked during the heat death of the universe, but it's probably not worth the effort.
-
My understanding was that the compatibility shims was added in Windows 2000. In any case, the point remains: nobody's going to say the Win32 API is a brilliant work of perfection, but when your application developers are diving into your data structures and fiddling with your bits, you're kind of fucked.
-
gitplaining
Fuck Vox and fuck whoever came up with "mansplaining." It was funny for about five minutes, and your term was funny for about a second and a half before it became annoying.
Rant not directed at you, btw, your word just set me off. Also, love the avater.
This mini-rant brought to you by the guy who thinks they built a bridge between the Gaza strip and the West Bank.
-
My understanding was that the compatibility shims was added in Windows 2000.
Still, hope your time capsule is pretty comfortable.
but when your application developers are diving into your data structures and fiddling with your bits, you're kind of fucked.
It doesn't stop Microsoft from screwing themselves over without help from the devs. Still, kinda agree with your point - I still think they should show a middle finger to those devs once in a while, but when people actually complain about lack of support for 16-bit applications in 2010s, it's probably not so easy.
-
It doesn't stop Microsoft from screwing themselves over without help from the devs.
Hah! At least Microsoft only fucks over their own customers.
The W3C's "referers" misspelling fucks over every single web developer in the history and future of mankind.
-
There is just a bit of a difference between this:
You don't get to make API changes, ever.
And this:
Note that you can (and probably should) version your API, or individual API calls. So you can write a new version of the API.
But the old version should continue working as well.
Until when? The heat death of the universe?
-
-
@Intercourse said:
Until when? The heat death of the universe?
Correct.
A bridge builder builds a bridge to last forever. Not a year, not a decade, not a century-- forever.
-
Correct.
A bridge builder builds a bridge to last forever. Not a year, not a decade, not a century-- forever.
Bad metaphor. Bridges have service lives. Just like everything else.
-
@Intercourse said:
Bad metaphor. Bridges have service lives. Just like everything else.
Of course.
But that doesn't change the fact that they're built to last forever.
-
But that doesn't change the fact that they're built to last forever.
Are you obtuse or retarded? No. They. Are. Not.
-
Oh well I can't compete with that many periods.
-
Damn right.
-
@Intercourse said:
Bridges have service lives.
Which is a "after this we can't guarantee that it is still safe to use". That is different than blowing it up when that time passes.
-
Oh well I can't compete with that many periods.
It's the missing periods you have to look out for.
-
Whether or not the metaphor is apt is not the point.
The point is, the ideal (there's that word "ideal" that I know people around here don't understand) product, whether a bridge or an API, has a lifetime of "forever". If you give a shit about your work, you build it to last forever.
-
@Intercourse said:
You should not change it often, and you should have a damn good reason when you do, but to say that you should never change it, ever, is just fucking stupid.
Depends what kind of change you mean. A change that adds a new call? OK. A change on how something is called or to remove a call? No (if you are removing due to security issues, patch the bug but leave the API alone).
Sorry, but I thinkgets()begs to differ, for good reason. (Hint: try compiling a program that calls it on a Linux box of any recent vintage.)
-
Ummmm... no one goes to greater lengths to provide backward compatibility for their APIs. Microsoft often puts in special work arounds so that horrible programs continue to function properly. They'll even bake a bug in as a backwards compatibility behavior if it benefits their customers to do so.
And that is just...wrong. If you have to put bugs back in to get your API to support applications, you are on the verge of drowning in legacy support costs.
It's the missing periods you have to look out for.
+1
Whether or not the metaphor is apt is not the point.
It is not whether or not your metaphor was apt, it was that it proved my point. Bridges have an EOL. You hope they last forever, but they don't. If you were a bridge engineer, and there was a critical design flaw discovered post-construction, you would just keep it there.
It is a fucking good thing you work in software and not in ergonomics or automobile engineering, or else my fucking SUV would have a tiller, hand brakes and an ignition retard, because we have to maintain legacy support until the end of fucking time.
-
@Intercourse said:
It is not whether or not your metaphor was apt, it was that it proved my point. Bridges have an EOL. You hope they last forever, but they don't. If you were a bridge engineer, and there was a critical design flaw discovered post-construction, you would just keep it there.
Jesus fucking shit. Yes they have an EOL. That has NOTHING to do with what I typed. NOTHING. NOTHING AT ALL.
It's impossible to communicate with people who can't read. Christ.
-
Ragequit, right around the corner.
-
Which is a "after this we can't guarantee that it is still safe to use". That is different than blowing it up when that time passes.
They won't blow up a bridge just because a set time passes, but absolutely will DOTs demolish a bridge that has become unsafe and it can't be reasonably repaired. Maybe not as much as they should (see I-35), but stuff like that definitely happens.Besides, the analogy is very different. Structural engineering as a practice is millenia old. That not only means we actually have some clue how to do it well (unlike writing good software) but we also know more what to expect in terms of uses. The nature of a bridge's use doesn't change. Bridges in Roman times do the same thing as bridges now. Everyone does pretty much the same thing when using a bridge as everyone else. (I'm not saying the design of bridges hasn't improved, to say the least, or that they don't carry heavier and more loads. I'm just saying that how you use a bridge is identical now as it was then.)
There's no bridge analogue to, say, the rebase vs merge argument in Git. If you drive across the bridge in the opposite lanes from everyone else, you'll get arrested. Literally no one sane thinks that's actually a good thing to do. But there's a big difference between the, say, 100 people that are using an early pre-alpha or alpha version of a piece of software (when blakeyrat apparently thinks that the UI design should be fixed) and 100,000 people (out-of-my-butt guess) that use Git now. It's a very different audience, and the initial 100 shouldn't be required to predict both who the audience will be in 10 years and what they want.
Finally, don't forget that the usual front-line Git UI is designed for people, not consumption by other software, and there's an entire set of subcommands that is explicitly designed to be stable to act as an API. (Admittedly, I don't know how much logic you have to duplicate to use it.)
-
Besides, the analogy is very different.
So let's say that instead of repairing a bridge, or even blowing it up and building a new one, the city had launched a private jet service over the river. Sure, it's shiny and possibly more efficient, but suddenly you get a couple thousands of people with no way to drive their cars home.
-
Fuck Vox and fuck whoever came up with "mansplaining." It was funny for about five minutes, and your term was funny for about a second and a half before it became annoying.
Rant not directed at you, btw, your word just set me off. Also, love the avater.
Minor nitpick: gitplaining was intended to be similar to bragplaining instead of mansplaining.
About the avatar: I actually changed it back to the old one last week, but this is Discourse, so only $DEITY knows what will happen.
@Intercourse said:
Ragequit, right around the corner.
Wishful thinking.
