Software disenchantment
-
@Cursorkeys said in Software disenchantment:
@blakeyrat said in Software disenchantment:
@Tsaukpaetra said in Software disenchantment:
OMG I found my new favorite alien car!
It shows you there are things the Europeans can do better than us Americans. Like making criminally hideous cars.
For example, our ugliest car is just the Pontiac Aztek:
Nice try, but we remember you guys made the PT Cruiser:
That was going to be my dream car in high school for some reason. Parents thought it was bizarre, but got me a scale model of a blue one for Christmas. How times have changed...
-
@admiral_p said in Software disenchantment:
@dkf said in Software disenchantment:
@blakeyrat said in Software disenchantment:
It's a fucking super model compared to that Fiat.
That Fiat is what you get when you take the top half of one vaguely OK looking car and weld it onto the bottom half of another vaguely OK looking car of a completely different size. I suppose there is one benefit with having them on the road: you know that anyone driving one has no æsthetic sense at all.
That Fiat is also one of the most comfortable and practical cars I have ever been into. Even fucking Jeremy Clarkson loves it.
Yeah but why do you buy a car? To sit comfortably inside, or to have something that looks nice?
They later redesigned it with a more conventional look. It is only then that we all realised, oh, but we liked it better before. At least it was memorable and had some soul in it.
I'm sure most people (at least outside Italy) would take the redesigned over original any day. At least I would. I don't want a car that's memorable for being abomination.
-
@Jaloopa said in Software disenchantment:
@Bulb said in Software disenchantment:
pretty good reference
@Bulb said in Software disenchantment:
sucked at actually explaining things
These are mutually incompatible
Only if you consider sucking to be a bad thing. Git users don't, apparently.
-
@Gąska said in Software disenchantment:
Yeah but why do you buy a car? To sit comfortably inside, or to have something that looks nice?
-
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
@dkf said in Software disenchantment:
@blakeyrat said in Software disenchantment:
It's a fucking super model compared to that Fiat.
That Fiat is what you get when you take the top half of one vaguely OK looking car and weld it onto the bottom half of another vaguely OK looking car of a completely different size. I suppose there is one benefit with having them on the road: you know that anyone driving one has no æsthetic sense at all.
That Fiat is also one of the most comfortable and practical cars I have ever been into. Even fucking Jeremy Clarkson loves it.
Yeah but why do you buy a car? To sit comfortably inside, or to have something that looks nice?
Neither. I buy car to get from point a to point b.
-
@Tsaukpaetra you're weird.
-
@Gąska said in Software disenchantment:
I still don't see how that makes it my responsibility to fix it.
In general, when you are the person who is seeing the problem and other people just aren't, it's quite difficult for you to persuade them to fix the problem (assuming that the problem exists and isn't something you've outright imagined or due to a misunderstanding somewhere). That means that if you want the problem sorted out, you have to take the lead in order to get somewhere, or find a group of like-minded people who between you will sort it out. Just sitting there and grumbling about it gets you nowhere at all. Those who are self-starting tend to attract far more respect than the idle grumblers.
In this specific case, you want a change to the git client as you believe that it is unintuitive in a number of areas. (I agree that the git command line client is spectacularly unintuitive, but I'm not convinced that what appear to be your desired changes will make it better. This is where my different model of how it works to you might be coming into play.) You can contribute by offering your time and programming effort, or by paying someone else to do it, or possibly even by putting in the effort to organise the other two; there's all sorts of ways to improve things. You might wish to make the new interface to git be a separate piece of software so that you have more freedom to change things; that could evolve into a contribution to git (if you can run the other-assholes gauntlet) or it might become its own product; that's not my decision as I don't currently want anything to do with all this. I'm too busy with my own stuff.
But sitting there and just grumbling? NO RESPECT FROM ME FOR THAT! Others might have the same opinion.
-
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
@dkf said in Software disenchantment:
@blakeyrat said in Software disenchantment:
It's a fucking super model compared to that Fiat.
That Fiat is what you get when you take the top half of one vaguely OK looking car and weld it onto the bottom half of another vaguely OK looking car of a completely different size. I suppose there is one benefit with having them on the road: you know that anyone driving one has no æsthetic sense at all.
That Fiat is also one of the most comfortable and practical cars I have ever been into. Even fucking Jeremy Clarkson loves it.
Yeah but why do you buy a car? To sit comfortably inside, or to have something that looks nice?
They later redesigned it with a more conventional look. It is only then that we all realised, oh, but we liked it better before. At least it was memorable and had some soul in it.
I'm sure most people (at least outside Italy) would take the redesigned over original any day. At least I would. I don't want a car that's memorable for being abomination.
This post is so Polish it makes me want to shout kurwa.
-
@Jaloopa said in Software disenchantment:
@Bulb said in Software disenchantment:
pretty good reference
@Bulb said in Software disenchantment:
sucked at actually explaining things
These are mutually incompatible
No. Something can be a good reference when you already know what it is about (and you just need to remember how something you already know how to do and what it is about is done) yet be impenetrable to novices. Reference manuals are written differently to "teaching" manuals. You don't usually want reference manuals to explain stuff, you want them to be straight to the point.
-
@dkf said in Software disenchantment:
@Gąska said in Software disenchantment:
I still don't see how that makes it my responsibility to fix it.
In general, when you are the person who is seeing the problem and other people just aren't, it's quite difficult for you to persuade them to fix the problem
Especially if you don't talk about the problem.
(assuming that the problem exists and isn't something you've outright imagined or due to a misunderstanding somewhere).
Are you implying all my problems with Git are just imaginations and misunderstanding?
That means that if you want the problem sorted out, you have to take the lead in order to get somewhere, or find a group of like-minded people who between you will sort it out.
And you do that by talking to people about problems.
Just sitting there and grumbling about it gets you nowhere at all.
No, but talking about problems definitely does. SVN didn't get branches because someone outside core dev team made a patch. It got branches because people started complaining en masse about lack of branches and started abandoning it in favor of Git, which didn't have the issues that SVN had to them. It was done by whining, not coding.
Those who are self-starting tend to attract far more respect than the idle grumblers.
Those who don't speak about issues tend to attract no following at all. Movements don't form around respect; they form around issues.
In this specific case, you want a change to the git client as you believe that it is unintuitive in a number of areas.
And I speak loudly about it to focus people's attention on those areas, hoping they'll notice the issues too, which will strengthen the group that wants a change.
(I agree that the git command line client is spectacularly unintuitive, but I'm not convinced that what appear to be your desired changes will make it better. This is where my different model of how it works to you might be coming into play.)
Figuring out the solution is step 2. Step 1 is making people acknowledge there is an issue at all. You can't have a discussion about solution if people don't agree what the problem is and that it needs fixing.
You can contribute by offering your time and programming effort, or by paying someone else to do it, or possibly even by putting in the effort to organise the other two; there's all sorts of ways to improve things.
I can also contribute by just spreading awareness that the problem exist, and by thinking up a solution without actually implementing it in code. In fact, implementing it in code without first taking care of the former two would be incredibly wasteful, as I'd be writing lots of code that nobody is going to use.
You might wish to make the new interface to git be a separate piece of software so that you have more freedom to change things; that could evolve into a contribution to git (if you can run the other-assholes gauntlet) or it might become its own product; that's not my decision as I don't currently want anything to do with all this. I'm too busy with my own stuff.
Guess what - I'm just as busy as you are! That's why I don't fancy spending several to several dozen man-months developing software no one is going to use - and no one is going to use it if they won't see the need to switch from Git. On the other hand, if majority of people will agree the change is needed, even if there's no working implementation of the change yet, some people (maybe myself) will start developing it - in particular, Git developers themselves might start feeling the need to fix their shit if they don't want to lose users.
-
@admiral_p said in Software disenchantment:
@Jaloopa said in Software disenchantment:
@Bulb said in Software disenchantment:
pretty good reference
@Bulb said in Software disenchantment:
sucked at actually explaining things
These are mutually incompatible
No. Something can be a good reference when you already know what it is about (and you just need to remember how something you already know how to do and what it is about is done) yet be impenetrable to novices.
That's not a good reference. That's the bare minimum you need to even call something a reference. Good means better than the bare minimum.
Reference manuals are written differently to "teaching" manuals. You don't usually want reference manuals to explain stuff, you want them to be straight to the point.
Actually, I do want reference manuals to explain stuff. Maybe not the fundamentals behind entire library, but at least a short version on what the function I'm looking at right now does. That totally falls under teaching.
-
@Gąska technically what drives change, even in your own words, is still somebody putting in the effort to make something better. Which drives users to switch.
Git was hurriedly coded in a few months to suit the kernel development's needs. As with any such project (I don't know the specifics) I guess the emphasis was in getting things done. And due to the size of the kernel, and knowing Linus Torvalds's mindset, the objectives will have been "it works well enough", "it's fast". Linux in general is an example of "it works well enough", "it's fast". I know Blakeyrat doesn't like this (yet he rails against "effete latte-sipping developers"; I bet the kernel's neckbeards think the same of him) but without this kind of approach shit wouldn't get done. Linux wouldn't have happened at all.
-
@admiral_p said in Software disenchantment:
@Gąska technically what drives change, even in your own words, is still somebody putting in the effort to make something better. Which drives users to switch.
It only creates the possibility to switch. The driver is always the (perceived) need. And if there's enough need but nothing to switch to, someone almost surely will create something to switch to.
Git was hurriedly coded in a few months to suit the kernel development's needs. As with any such project (I don't know the specifics) I guess the emphasis was in getting things done. And due to the size of the kernel, and knowing Linus Torvalds's mindset, the objectives will have been "it works well enough", "it's fast".
It's like they did everything they could to make sure Git would be horrible to use.
Linux in general is an example of "it works well enough", "it's fast".
For a very loose definition of "well enough".
I know Blakeyrat doesn't like this (yet he rails against "effete latte-sipping developers"; I bet the kernel's neckbeards think the same of him) but without this kind of approach shit wouldn't get done. Linux wouldn't have happened at all.
Wrong. It would most likely still happen. Just a bit later. And in different form. Thinking things through first isn't a road to failure. A prime counterexample is Rust - a language (and an ecosystem) that's been in beta for years, not because of lack of manpower but because they wanted to design it well right from the start. They've put solid work behind the theoretical foundations of the language and the standard library, and this design really paid off - it's now become the most loved language in various opinion polls, and it's gaining popularity at rapid pace.
-
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
@Gąska technically what drives change, even in your own words, is still somebody putting in the effort to make something better. Which drives users to switch.
It only creates the possibility to switch. The driver is always the (perceived) need. And if there's enough need but nothing to switch to, someone almost surely will create something to switch to.
Git was hurriedly coded in a few months to suit the kernel development's needs. As with any such project (I don't know the specifics) I guess the emphasis was in getting things done. And due to the size of the kernel, and knowing Linus Torvalds's mindset, the objectives will have been "it works well enough", "it's fast".
It's like they did everything they could to make sure Git would be horrible to use.
Linux in general is an example of "it works well enough", "it's fast".
For a very loose definition of "well enough".
I know Blakeyrat doesn't like this (yet he rails against "effete latte-sipping developers"; I bet the kernel's neckbeards think the same of him) but without this kind of approach shit wouldn't get done. Linux wouldn't have happened at all.
Wrong. It would most likely still happen. Just a bit later. And in different form. Thinking things through first isn't a road to failure. A prime counterexample is Rust - a language (and an ecosystem) that's been in beta for years, not because of lack of manpower but because they wanted to design it well right from the start. They've put solid work behind the theoretical foundations of the language and the standard library, and this design really paid off - it's now become the most loved language in various opinion polls, and it's gaining popularity at rapid pace.
History is important. When Linux was first made, it was a hobbyist project that succeeded for lots of serendipitous reasons (choice of computer architecture, licensing issues with the BSDs, support by GNU, relatively deficient competition, a certain element of "hacker culture"). Grand designs didn't matter (in fact a large portion of open source is not innovative at a basic level - maybe it is on a technical level in specific niches - but it is often "like <whatever>, but free"), what mattered is that it existed and worked well enough. In general, design only matters once you can afford to care about it. Rust exists because after building up decades of experience, gotchas, headaches, etc. you can afford to take the time to design it, while you can still use C/C++/Java/whatever in production. A new open source kernel might come along some day (will Fuchsia/Zircon ever come to fruition?) and it can afford to take all the time it needs to make sure not to repeat the mistakes of the past because people complain about stuff all the time but it still works decently enough.
By the way, a decent, sane language already exists and had existed for decades, and that's Ada. The only problem with it is that its syntax is Pascal-like instead of C-like (in my view, that's a bonus), and probably (I'm not sure) it has some problems interfacing with C APIs (while Rust is designed to fit in a C world).
-
@admiral_p said in Software disenchantment:
History is important.
If you want to explain the design, not if you want to evaluate if something is good. "Git is a good tool because it was created by hobbyists" is probably the most bullshit argument imaginable.
@admiral_p said in Software disenchantment:
In general, design only matters once you can afford to care about it.
The only way you might possibly not afford to have good design is if you have a deadline looming and financial penalties if you don't meet it. Hobbyist projects don't have deadlines or financial penalties. They don't have this excuse. It's not that they couldn't afford. It's that they couldn't care. Because they're hackers who don't see hacky workarounds for everything as a bad thing.
-
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
History is important.
If you want to explain the design, not if you want to evaluate if something is good. "Git is a good tool because it was created by hobbyists" is probably the most bullshit argument imaginable.
Git is good because it allowed the kernel to continue to be developed, and because at the time, many of its issues might not have been clearly predictable.
@admiral_p said in Software disenchantment:
In general, design only matters once you can afford to care about it.
The only way you might possibly not afford to have good design is if you have a deadline looming and financial penalties if you don't meet it. Hobbyist projects don't have deadlines or financial penalties. They don't have this excuse. It's not that they couldn't afford. It's that they couldn't care. Because they're hackers who don't see hacky workarounds for everything as a bad thing.
No, even hobbyists want their stuff to be used, especially in a world where the alternatives are only proprietary/commercial. Lacking the time, the manpower, etc. to actually stop and think, it is better to just ship and possibly think about it later. Or simply, the pain points are addressed by another, different project.
-
@admiral_p said in Software disenchantment:
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
History is important.
If you want to explain the design, not if you want to evaluate if something is good. "Git is a good tool because it was created by hobbyists" is probably the most bullshit argument imaginable.
Git is good because it allowed the kernel to continue to be developed
There's million other ways they could've continued developing kernel. Git's creation had nothing to do with ability to continuing their work. It's just they've decided it's more convenient for them to make a new tool instead of using any existing one. But it didn't really open any new possibilities. They could've instead become Zen-like about weaknesses of SVN or whatever and just carry on.
But even if it was critical to continuing work on Linux. This doesn't say anything about quality of Git itself.
and because at the time, many of its issues might not have been clearly predictable.
It takes a special kind of dumb to not predict that making a single command do three completely different things depending on what arguments have been passed might cause issues.
@admiral_p said in Software disenchantment:
In general, design only matters once you can afford to care about it.
The only way you might possibly not afford to have good design is if you have a deadline looming and financial penalties if you don't meet it. Hobbyist projects don't have deadlines or financial penalties. They don't have this excuse. It's not that they couldn't afford. It's that they couldn't care. Because they're hackers who don't see hacky workarounds for everything as a bad thing.
No, even hobbyists want their stuff to be used, especially in a world where the alternatives are only proprietary/commercial.
And how exactly does releasing things earlier help that? Hobbyists are free. There's no budget to worry about. Marketing can wait. Everything can wait. Release date doesn't matter. You can totally afford spending 1-2 months on proper design. Because 1-2 months is all it takes in most cases.
Lacking the time, the manpower, etc. to actually stop and think, it is better to just ship and possibly think about it later.
It isn't. Or rather, it's good short-term, but very bad long-term. In fact, this kind of thinking is the direct reason of everything that the article in OP complains about.
Or simply, the pain points are addressed by another, different project.
Which doesn't solve anything until people actually move to that other project. If it was IDE or something like that, it wouldn't matter because all I care about is what I use myself. But VCS is special because it's collaboration tool, and it has to be one tool among all collaborating people. So it's not sufficient for me alone to make the switch.
-
@Gąska You've atomised my message into piece smaller than a paragraph. I refuse to read your response as it is inevitably bound to be missing the point.
-
@dkf you should deliver your message into smaller commits, it's easier to review
-
@dkf said in Software disenchantment:
@Gąska You've atomised my message into piece smaller than a paragraph. I refuse to read your response as it is inevitably bound to be missing the point.
Here's my entire response to your entire paragraph:
It's difficult to persuade people about a problem if you don't talk about the problem. That's why I don't avoid talking about the problem even though I don't have a patch ready.
SVN didn't get branches because someone outside core dev team made a patch. It got branches because people started complaining en masse about lack of branches and started abandoning it in favor of Git, which didn't have the issues that SVN had to them. It was done by whining, not coding.
Those who don't speak about issues tend to attract no following at all. Movements don't form around respect; they form around issues.
I speak loudly about issues with Git to focus people's attention on those areas, hoping they'll notice the issues too, which will strengthen the group that wants a change.
It doesn't matter that I don't have a solution ready. Figuring out the solution is step 2. Step 1 is making people acknowledge there is an issue at all. You can't have a discussion about solution if people don't agree what the problem is and that it needs fixing.
In addition to programming, and paying someone to do programming, I can also contribute by just spreading awareness that the problem exist, and by thinking up a solution without actually implementing it in code. In fact, implementing it in code without first taking care of the former two would be incredibly wasteful, as I'd be writing lots of code that nobody is going to use.
Guess what - I'm just as busy as you are! That's why I don't fancy spending several to several dozen man-months developing software no one is going to use - and no one is going to use it if they won't see the need to switch from Git. On the other hand, if majority of people will agree the change is needed, even if there's no working implementation of the change yet, some people (maybe myself) will start developing it - in particular, Git developers themselves might start feeling the need to fix their shit if they don't want to lose users.
-
@dkf said in Software disenchantment:
@Gąska You've atomised
Unfortunately, he's still in one piece
@dkf said in Software disenchantment:
my message into piece
take me to your leader
@dkf said in Software disenchantment:
smaller than a paragraph. I refuse to read
What, you only read passages longer than a paragraph?
@dkf said in Software disenchantment:
your response as it is inevitably bound to be missing the point.
TDEMSYR
-
At the risk of being yelled at by
bothall sides of the debate for trying to derail the thread, has anyone tried using Fossil? I mean, there might be reasons why it could be even worse than Git for a given project/developer, but it looks like a sane choice for small or personal projects.I found it while looking for a VCS for my colleagues that would be simple to install (check: just put a single exe file where you want) and set up on Windows, because Git was very bumpy last time I tried it (some of its parts confused the file name encodings and I ended up with my SSH keys in
C:\Documents and Settings\└ыхъёрэфЁ; the whole notion of SSH would probably confuse people with no prior experience; also, shipping Perl 5.8 in the whole package is just plain wrong). As a bonus, Fossil can run a website with wiki and a ticketing system to go with the project.Alas, one of the colleagues told me that he wanted to try Git, then had to finish an article urgently and forgot about the whole thing, while another one still thinks that VCS is no better than a backup system and just e-mails diffs and full ZIPs of source code with binaries.
-
@aitap said in Software disenchantment:
Fossil can run a website with
wikia Discourse forum and aticketing systemDiscourse forum to go with the project.FTFY
-
@Cursorkeys The PT Cruiser was kind of retro-classy when it first came out. Certainly not even close to the same ugliness level of the Aztek. At least it has a consistent look, which is a blend of the 1950s and the 1990s when it was made.
And since I drove one for years, it was a basically reliable car that had a great sitting position. (You sat upright like in a SUV, but it wasn't any bigger than a normal car. Large back seats, too.)
-
@admiral_p said in Software disenchantment:
That Fiat is also one of the most comfortable and practical cars I have ever been into.
Did you know the Pontiac Aztek has a tent built-in to the tailgate? An honest-to-goodness "going camping tonight" tent.
(Not sure if that's points in its favor or against.)
-
@dkf Ok.
There are two huge obstacles here people have mentioned:
- Most of Git's flaws are due to the program being badly-designed at the very core, which prevents fixes being made now. For example, none of the UI problems with the CLI client can be fixed because of Git's stupid stupid stupid decision to make the user interface the same interface as the programmatic interface. Meaning, any Git client can only communicate to Git by sending CLI commands, meaning all of those badly-named and terribly-designed commands are now set in stone and can't be fixed.
- That aside, the second barrier is to be able to change how Git functions, you have to convince the people who maintain Git that it needs to change. That's not something that'll ever happen. Superman couldn't pull that off. So it'd be completely pointless for me or anybody to learn C, learn the Git build, learn Linux, build the patch, do the testing, and submit the PR for a PR that'd NEVER be accepted.
Git was designed by idiots who don't know what the fuck they were doing and have no business being in software development. In any SANE industry, they would have been tarred and feathered. Now those same idiots are in charge of maintaining it, and we're all just fucked.
-
@admiral_p said in Software disenchantment:
Git was hurriedly coded in a few months to suit the kernel development's needs.
Ok; but what's the excuse for it being so badly designed? You can write software quickly and still keep the user interface detached from the programmatic interface.
No, it's badly-designed because either:
- Linus doesn't have any idea how to write good software, or
- Linus wrote Git specifically to be hostile to people who prefer a GUI
I'm not sure which, but again: either should have gotten him tarred and feathered.
@admiral_p said in Software disenchantment:
I know Blakeyrat doesn't like this (yet he rails against "effete latte-sipping developers"; I bet the kernel's neckbeards think the same of him)
I don't even remember what that was in context of, but it certainly wasn't Linux kernel developers. Those are angry old guys who want computers to run exactly how they did in 1985, because that's the last time they got any respect as the "high priesthood of technology".
The effete latte-sipping developers are the ones who write stuff like Discord, where they write web-based shit and spend a ton of time making the product "fun" without any consideration whether it's actually good or not.
Totally different type of terrible software developer. And the latte-sipping stereotype would write something way better than Git. (I mean, pretty much anybody would.)
@admiral_p said in Software disenchantment:
Linux wouldn't have happened at all.
And you're suggesting that is... ... ...bad?
-
@blakeyrat Again, no. The goal was not for it to be widely used in production, the goal was to make something quickly that worked. It is not Torvalds' fault that industry leaders use it, it is the fault of each industry leader.
-
@admiral_p said in Software disenchantment:
History is important.
It doesn't matter if Jesus Himself came down the mountain with Git 1.0 on two stone tablets.
I'm using Git in 2018 and it's shitty now. I don't give a shit what its history is.
@admiral_p said in Software disenchantment:
Git is good because it allowed the kernel to continue to be developed, and because at the time, many of its issues might not have been clearly predictable.
Bull-fucking-shit. He wrote it in 2007. It wasn't some kind of shocking new revelation in 2007 that it's a good idea to separate your user interface from your programmatic interface; Apple and Microsoft have both been encouraging that from the mid-1990s.
No; the problem here is that Linus Torvalds is incompetent and doesn't know what the fuck he's doing. (Either that, or as I've mentioned above, he purposefully sabotaged his software to make it difficult to use.)
-
@pie_flavor Yes, it is his fault he made something shitty.
-
@blakeyrat also, anything that needs cygwin to run properly on windows is unsupported shit IMO.
I
-
@aitap said in Software disenchantment:
At the risk of being yelled at by bothall sides of the debate for trying to derail the thread, has anyone tried using Fossil? I mean, there might be reasons why it could be even worse than Git for a given project/developer, but it looks like a sane choice for small or personal projects.
I've used it for years for most of my personal projects and a few larger projects as well. (My largest fossil checkout DB is about 324MB right now with more commits than I care to try counting, but I've not vacuumed the DB for some time so there's that…) One of the nice things is that you usually only have one actual copy of the database cloned from the outside world, and each checkout made from that is lightweight (at a cost of sharing local state, which is usually OK). It's definitely targeted at smaller projects than git, but that's only 99% of all projects.
It does all its UI by delivering HTML that your browser renders. Because who wants to reinvent a front-end client from scratch? Most features you ever care about are pretty discoverable that way. A few aren't (and there's no facility for online editing of main content via the web a la github) but they're fairly obscure stuff…
The main problem is that it has much less mature IDE integration. If that's a dealbreaker, so be it (or get coding to fix the situation, of course). I know that you can do minor integration with Emacs (which isn't particularly great, but…) yet I don't know of anything for actual IDEs (which Emacs isn't if you're not writing Lisp).
As a bonus, Fossil can run a website with wiki and a ticketing system to go with the project.
More usefully than the rudimentary wiki support, you can pull versioned files out of the revision history and base your web content on that. That's actually useful (and I used it a fair bit). The ticketing is OK, and fairly customizable by people with admin access to a particular instance (e.g., yourself on your own instance) though without much complex task-flow support. And you can poke around in the underlying database itself if you prefer, or do scripting of triggers and stuff but that's where I've not dug around in detail.
-
@blakeyrat said in Software disenchantment:
No, it's badly-designed because either:
- Linus doesn't have any idea how to write good software, or
- Linus wrote Git specifically to be hostile to people who prefer a GUI
I vote both.
-
@blakeyrat said in Software disenchantment:
@dkf Ok.
There are two huge obstacles here people have mentioned:
- Most of Git's flaws are due to the program being badly-designed at the very core, which prevents fixes being made now. For example, none of the UI problems with the CLI client can be fixed because of Git's stupid stupid stupid decision to make the user interface the same interface as the programmatic interface. Meaning, any Git client can only communicate to Git by sending CLI commands, meaning all of those badly-named and terribly-designed commands are now set in stone and can't be fixed.
- That aside, the second barrier is to be able to change how Git functions, you have to convince the people who maintain Git that it needs to change. That's not something that'll ever happen. Superman couldn't pull that off. So it'd be completely pointless for me or anybody to learn C, learn the Git build, learn Linux, build the patch, do the testing, and submit the PR for a PR that'd NEVER be accepted.
Git was designed by idiots who don't know what the fuck they were doing and have no business being in software development. In any SANE industry, they would have been tarred and feathered. Now those same idiots are in charge of maintaining it, and we're all just fucked.
It still isn't impossible to use git in the background and write an application (maybe even a script, or a bunch of aliases) with whatever sane UI you can think of, which make it more pleasurable for the user to actually use git.
-
@blakeyrat said in Software disenchantment:
Most of Git's flaws are due to the program being badly-designed at the very core, which prevents fixes being made now. For example, none of the UI problems with the CLI client can be fixed because of Git's stupid stupid stupid decision to make the user interface the same interface as the programmatic interface. Meaning, any Git client can only communicate to Git by sending CLI commands, meaning all of those badly-named and terribly-designed commands are now set in stone and can't be fixed.
There's a bunch of commands in there that are designed to be program driven. They're really hostile to use interactively — I've used 'em occasionally for doing major surgery on the repo prior to doing a public clean version, and it wasn't pleasant (at least it was possible) — but work well as stuff that you can drive from advanced tools like a GUI/IDE. I'd guess that using these things to make the glue would make the job easier, but I have no idea what guides have been written on doing it.
These tools work at the hypergraph level of git, which is the lowest level that anyone should touch that isn't tinkering with the actual on-disk storage mechanisms.
That aside, the second barrier is to be able to change how Git functions, you have to convince the people who maintain Git that it needs to change. That's not something that'll ever happen. Superman couldn't pull that off. So it'd be completely pointless for me or anybody to learn C, learn the Git build, learn Linux, build the patch, do the testing, and submit the PR for a PR that'd NEVER be accepted.
It doesn't need to be part of the core of git. Nobody's forcing that except perhaps you and your (
$INSERT_EXPLETIVES) management. If lots of people try it as a third-party system and like it, you can make a much better case for taking it core if you choose and you're more likely to find other people to help. But you never need to choose to do that.Making it be part of git itself is your imagined issue.
Git was designed by idiots who don't know what the fuck they were doing and have no business being in software development. In any SANE industry, they would have been tarred and feathered. Now those same idiots are in charge of maintaining it, and we're all just fucked.
You've got my agreement there.
-
@admiral_p said in Software disenchantment:
It still isn't impossible to use git in the background and write an application (maybe even a script, or a bunch of aliases) with whatever sane UI you can think of, which make it more pleasurable for the user to actually use git.
Yes it is impossible. Do you think I could do better at it than, say, Microsoft when they wrote the Git interface for Visual Studio? No, I could not. And their Git interface sucks, as do all of them. Because Git is specifically designed to sabotage people making GUIs from it.
Let's take a hypothetical. You're writing a Git GUI. You come across a repo with a post-commit hook. How do you display output of that to the user? Do you feel lucky, punk? Well, do you?
-
@blakeyrat said in Software disenchantment:
@admiral_p said in Software disenchantment:
It still isn't impossible to use git in the background and write an application (maybe even a script, or a bunch of aliases) with whatever sane UI you can think of, which make it more pleasurable for the user to actually use git.
Yes it is impossible. Do you think I could do better at it than, say, Microsoft when they wrote the Git interface for Visual Studio? No, I could not. And their Git interface sucks, as do all of them. Because Git is specifically designed to sabotage people making GUIs from it.
Let's take a hypothetical. You're writing a Git GUI. You come across a repo with a post-commit hook. How do you display output of that to the user? Do you feel lucky, punk? Well, do you?
I'm not an expert, anyway, you can start by redirecting the hook's output to the console. I think the only way you can really solve the problem is by integrating whatever you need to do in the hook in git itself, and/or restrict what hooks can do (but this is the realm of policy).
-
@dkf said in Software disenchantment:
[Fossil] does all its UI by delivering HTML that your browser renders
Wait...there's no CLI for it? That's a nonstarter for me.
-
@boomzilla said in Software disenchantment:
@dkf said in Software disenchantment:
[Fossil] does all its UI by delivering HTML that your browser renders
Wait...there's no CLI for it? That's a nonstarter for me.
No, there is a CLI. But
fossil uiis implemented as an HTTP server.
-
@admiral_p said in Software disenchantment:
I'm not an expert, anyway, you can start by redirecting the hook's output to the console.
What console? You're writing a GUI, remember? (You do know what a GUI is, right?)
@admiral_p said in Software disenchantment:
I think the only way you can really solve the problem is by integrating whatever you need to do in the hook in git itself,
But you're not writing Git, you're writing a GUI for Git. Remember? You're out-of-scope.
@admiral_p said in Software disenchantment:
and/or restrict what hooks can do (but this is the realm of policy).
How do you do that exactly?
And post-commit hooks are just one example of how Git is utterly hostile to anybody trying to write a better UI for it. One of hundreds.
-
@blakeyrat said in Software disenchantment:
And post-commit hooks are just one example of how Git is utterly hostile to anybody trying to write a better UI for it.
Do you mean the concept of a post commit hook or the way that git implements them? I'm unclear on what you mean based on the stuff above where you asked how the GUI could convey information about this process. So I'm asking instead of attempting to mind read.
-
@boomzilla said in Software disenchantment:
Do you mean the concept of a post commit hook or the way that git implements them?
Kind of both.
The concept could be done well if Git had a well-defined plug-in system with well-defined input and output formats and then hooks were implemented as plug-ins following that standard.
But Git doesn't do that. What it does is garbage.
@boomzilla said in Software disenchantment:
I'm unclear on what you mean based on the stuff above where you asked how the GUI could convey information about this process. So I'm asking instead of attempting to mind read.
The point is post-commit hooks can output messages, right? But right now there's no way to display those messages in a reasonable fashion in a GUI, because there's absolutely no format defined for them.
So if you're writing a GUI, you have two choices:
- Just show a fucking dialog box with the output of the post-commit hook in a big-ass text field and just hope and pray the hook outputs something reasonable and actionable
- Don't support them at all
(Most choose option 2, but I think SourceTree, the shittiest of shitty Git GUI clients, does the former.)
-
@blakeyrat said in Software disenchantment:
Git was designed by idiots who don't know what the fuck they were doing and have no business being in software development.
Let's dispel this fiction once and for all that Linus Torvalds doesn't know what he's doing. He knows exactly what he's doing.
-
@Gąska said in Software disenchantment:
Let's dispel this fiction once and for all that Linus Torvalds doesn't know what he's doing. He knows exactly what he's doing.
Then you believe he made Git terrible on purpose?
That's actually worse.
-
@Gąska said in Software disenchantment:
Or if we wait a few more years, Pijul, which offers a groundbreaking new perspective on merging and conflict resolution.
Quick summary of what it does for the
?
-
@admiral_p said in Software disenchantment:
@blakeyrat said in Software disenchantment:
@dkf Ok.
There are two huge obstacles here people have mentioned:
- Most of Git's flaws are due to the program being badly-designed at the very core, which prevents fixes being made now. For example, none of the UI problems with the CLI client can be fixed because of Git's stupid stupid stupid decision to make the user interface the same interface as the programmatic interface. Meaning, any Git client can only communicate to Git by sending CLI commands, meaning all of those badly-named and terribly-designed commands are now set in stone and can't be fixed.
- That aside, the second barrier is to be able to change how Git functions, you have to convince the people who maintain Git that it needs to change. That's not something that'll ever happen. Superman couldn't pull that off. So it'd be completely pointless for me or anybody to learn C, learn the Git build, learn Linux, build the patch, do the testing, and submit the PR for a PR that'd NEVER be accepted.
Git was designed by idiots who don't know what the fuck they were doing and have no business being in software development. In any SANE industry, they would have been tarred and feathered. Now those same idiots are in charge of maintaining it, and we're all just fucked.
It still isn't impossible to use git in the background and write an application (maybe even a script, or a bunch of aliases) with whatever sane UI you can think of, which make it more pleasurable for the user to actually use git.
Proof by reality: it's been 11 years and no one has yet made such a thing.
-
@blakeyrat said in Software disenchantment:
It shows you there are things the Europeans can do better than us Americans. Like making criminally hideous cars.
For someone who uses every chance he gets to point out how much our IT industry lacks behind, bringing up cars is a pretty bold move. Nice flamebait though.
-
@dkf said in Software disenchantment:
That aside, the second barrier is to be able to change how Git functions, you have to convince the people who maintain Git that it needs to change. That's not something that'll ever happen. Superman couldn't pull that off. So it'd be completely pointless for me or anybody to learn C, learn the Git build, learn Linux, build the patch, do the testing, and submit the PR for a PR that'd NEVER be accepted.
It doesn't need to be part of the core of git. Nobody's forcing that except perhaps you and your (
$INSERT_EXPLETIVES) management. If lots of people try it as a third-party system and like it, you can make a much better case for taking it core if you choose and you're more likely to find other people to help. But you never need to choose to do that.Making it be part of git itself is your imagined issue.
It's making it part of Git, or maintaining it forever after - and it means either porting every single change done in upstream, or never updating your fork (which might become issue if people want to integrate it with IDE).
-
@topspin said in Software disenchantment:
For someone who uses every chance he gets to point out how much our IT industry lacks behind, bringing up cars is a pretty bold move. Nice flamebait though.
Right; that couldn't possibly have been a joke. You're a real Sherlock.
-
@admiral_p said in Software disenchantment:
@blakeyrat said in Software disenchantment:
@admiral_p said in Software disenchantment:
It still isn't impossible to use git in the background and write an application (maybe even a script, or a bunch of aliases) with whatever sane UI you can think of, which make it more pleasurable for the user to actually use git.
Yes it is impossible. Do you think I could do better at it than, say, Microsoft when they wrote the Git interface for Visual Studio? No, I could not. And their Git interface sucks, as do all of them. Because Git is specifically designed to sabotage people making GUIs from it.
Let's take a hypothetical. You're writing a Git GUI. You come across a repo with a post-commit hook. How do you display output of that to the user? Do you feel lucky, punk? Well, do you?
I'm not an expert, anyway, you can start by redirecting the hook's output to the console.
What console? You're in GUI world now.
I think the only way you can really solve the problem is by integrating whatever you need to do in the hook in git itself
Wow. Just wow. You may not realize it since you don't know shit about programming, but this the dumbest thing you've ever said, and probably will ever say on this forum. Things that go in commit hooks simply don't belong inside Git itself. They just don't.
