Software disenchantment
-
@topspin said in Software disenchantment:
@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
?Short version: you can merge branches and resolve conflicts in two separate commits. And this enables you to do many cool things, like rolling back resolution but not merge, merge more than two branches and resolve conflicts only once, or cherry-pick bugfixes to branches with unresolved conflicts without worrying about them.
-
@blakeyrat That's why I said "nice".
-
@Gąska said in Software disenchantment:
It's making it part of Git, or maintaining it forever after
Those are the “if you're lucky” options. Most software gets forgotten and lost in the mists of time, and most of that is for the best overall…
-
@Gąska said in Software disenchantment:
@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.
Is a GUI (a programming GUI, by the way) showing an occasional console window when the output does not match the predicted output such an abomination?
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.
Why not? They are automated scripts which are run in certain circumstances. They do not belong to Git but they could (as in, you extend the scope of Git to include certain not-strictly-Git functionality, just like systemd integrates basically everything). Or you could design a plugin system (with clear limitations on what plugins can do), or you can code a companion for Git which can do whatever you may need to do, securely, predictably and in a way that can be GUIfied. There are lots of things one could theoretically do. Not necessarily they can actually be done. (The latter for example can be done but you have to hope it gains traction).
-
@dkf no, that's not the problem. I don't want to maintain Git fork.
-
@admiral_p said in Software disenchantment:
Is a GUI (a programming GUI, by the way) showing an occasional console window when the output does not match the predicted output such an abomination?
Yes.
And don't fucking say "a programming GUI" as if this means it can be shitty and incomplete. That's what started this whole conversation in the first place. It's wrong, it's stupid, it's awful, stop saying it, stop thinking it.
-
@Gąska said in Software disenchantment:
Short version: you can merge branches and resolve conflicts in two separate commits.
I'm curious… Which comes first? The resolution or the merge? I guess the resolution, since the other way would leave the conflict in the commit and that's probably a bad idea. Hmm…
There is absolutely no reason why you couldn't write a branch-merging tool which does this, and that would definitely be the first step in proving the value to others. I'm not sure what state you'd need to maintain locally to make it all work, but I'm certain you can. In particular, there's no reason why auto-committing the result of a merge is required; that's something about git that I find weird as heck. I'm certain that not everyone will want to work that way; some people prefer entirely different ways of working that are potentially incompatible (as the resolved state may be not buildable) but you really can't please everyone.
Practically, you'd probably make a temporary local branch while doing the conflict resolution, and then nuke that branch once everything is working. Which is possible in a DVCS because branches are cheap (and purely local tags are just a label for a particular state, nothing more).
-
@blakeyrat said in Software disenchantment:
@admiral_p said in Software disenchantment:
Is a GUI (a programming GUI, by the way) showing an occasional console window when the output does not match the predicted output such an abomination?
Yes.
And don't fucking say "a programming GUI" as if this means it can be shitty and incomplete. That's what started this whole conversation in the first place. It's wrong, it's stupid, it's awful, stop saying it, stop thinking it.
Then you can still fix this by proposing a distribution of integrated tools designed to work with git in ways that make using git itself less unpleasant. It's not impossible. Maybe it's unfeasible (because you need time, effort and also some "marketing"... but everything starts as a bet really), but not impossible.
-
@blakeyrat said in Software disenchantment:
@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.
What would a good GUI (for a whatever-non-git VCS) do for a post-commit hook?
-
@topspin said in Software disenchantment:
What would a good GUI (for a whatever-non-git VCS) do for a post-commit hook?
It can't be done. That's exactly my point.
-
@dkf said in Software disenchantment:
@Gąska said in Software disenchantment:
Short version: you can merge branches and resolve conflicts in two separate commits.
I'm curious… Which comes first? The resolution or the merge? I guess the resolution, since the other way would leave the conflict in the commit and that's probably a bad idea. Hmm…
The trick is that Pijul uses a different conceptual model of repository, one where having unresolved conflicts isn't bad at all. More reading here.
If you want to talk about it further, we should probably make a new topic.
-
@blakeyrat So you wouldn't allow hooks at all?
-
@topspin I posted above how I would have implemented them, had it been my job to do so.
-
@blakeyrat said in Software disenchantment:
@boomzilla said in Software disenchantment:
@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
It's...text. GUIs can display that. Most of a typical IDE's real estate is devoted to text. I'm not sure what sort of thing you'd want to see here.
-
@admiral_p said in Software disenchantment:
@Gąska said in Software disenchantment:
@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.
Is a GUI (a programming GUI, by the way) showing an occasional console window when the output does not match the predicted output such an abomination?
And how exactly do you determine what output is unexpected? How do you extract the expected part from unexpected output (because you have to extract and parse the output, if only to know whether operation succeeded or not)? Really, there are dozens of corner cases you need to be aware of when making such tools, and the further you go, the more problems you encounter. Believe me, software development is much harder than it looks.
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.
Why not?
Are you seriously asking why putting repo-specific stuff inside Git core is a bad idea? Or are you simply unaware that hooks usually consists of things that are extremely repo specific, like accessing issue trackers, sending emails, performing intranet authorization - things that literally nobody outside this one specific team working on this one specific product would have any use of.
Or you could design a plugin system (with clear limitations on what plugins can do), or you can code a companion for Git which can do whatever you may need to do, securely, predictably and in a way that can be GUIfied.
At this point, we leave the "Git GUI" realm and enter the land of "let's create entirely new tool that will not work seamlessly with Git". Which is almost identical to not using Git at all, except you still have to use Git.
There are lots of things one could theoretically do.
But not if your goal is to make wrapper around Git. I know, for non-programmers, the difference between "make your GUI compatible with hooks" and "make hooks compatible with your GUI" might sound like minor semantical pedantry, but believe me, the difference is actually fundamental. And you should believe me, if only because I'm an actual professional software developer and you aren't.
-
@Gąska said in Software disenchantment:
the goal of Pijul is to build a tool whose behavior matches intuition, which hopefully will allow people with different skills to work together on the same project, even at fast paces.
That sounds like it's supposed to address some of the more valid complaints about git.
(I'm honestly not buying the part where git is irreparably bad because you don't like the names of the commands)Pijul is inspired by a result from category theory,
Oh boy. Ohh boy.
I haven't read all of it yet, so this is just jesting, but if you remember the xkcd where git is a "beautiful distributed graph theory model", which in reality turns out to be just computer science masturbation, then coming from category theory should make things infinitely worse.
-
@Gąska said in Software disenchantment:
The trick is that Pijul uses a different conceptual model of repository, one where having unresolved conflicts isn't bad at all.
Hmm… looking through that link you might like Fossil. That keeps metadata about where a cherry-picked commit came from and uses a really very different theory of branching to git (except at the hypergraph level, which is really quite a hard-core view for most folks; the actual difference is in theory of labelling of branches, but even most programmers never grasp that subtlety) that makes divergences much less fatal. You still need to solve them eventually if you want to get everyone's changes in use, but that's going to be true whatever: one of the main points of any VCS is to enable people to do that fixing.
The actual hypergraph theory (and associated universal state label theory) underlying all this is highly flexible and describes all of this stuff. (I would note that Pijul must be also storing histories as well as patches; people definitely care about histories as well as current states.)
-
@topspin said in Software disenchantment:
computer science masturbation
The thing about CS masturbation is that it actually has an impact on what you can do. The non-fancy way of doing this all produced things like SCCS and CVS, whereas applying more theory allowed us to fix the crippling faults in those and lead to the better systems we have. Bad models can be patched over, but not completely hidden (because abstractions leak); good models enable far more with less effort, and don't cause quite such large disasters when they leak…
-
@blakeyrat said in Software disenchantment:
@topspin said in Software disenchantment:
What would a good GUI (for a whatever-non-git VCS) do for a post-commit hook?
It can't be done. That's exactly my point.
Oh, right. Just because it's hard we should give up on it
-
@boomzilla said in Software disenchantment:
@blakeyrat said in Software disenchantment:
@boomzilla said in Software disenchantment:
@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
It's...text. GUIs can display that. Most of a typical IDE's real estate is devoted to text. I'm not sure what sort of thing you'd want to see here.
I can't believe I'm agreeing with Blakey here, but the point is that it's unformatted text. Just a big ol text bomb. It might be a constantly updated progress bar, and it might be a list of all files updated, and it might be ASCII art of Ben's dog. A proper system would, for instance, have ways of communicating things like updated files other than stdout.
-
@Jaloopa said in Software disenchantment:
Oh, right. Just because it's hard we should give up on it
The concept of a post-commit hook could be done nicely in a GUI. No problem at all. Hell, there's a product called FinalBuilder that has pretty much EXACTLY THAT.
Git's implementation of that concept is hopelessly awful. It needs to be burned down and rebuilt from scratch.
-
@pie_flavor said in Software disenchantment:
@boomzilla said in Software disenchantment:
@blakeyrat said in Software disenchantment:
@boomzilla said in Software disenchantment:
@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
It's...text. GUIs can display that. Most of a typical IDE's real estate is devoted to text. I'm not sure what sort of thing you'd want to see here.
I can't believe I'm agreeing with Blakey here, but the point is that it's unformatted text. Just a big ol text bomb. It might be a constantly updated progress bar, and it might be a list of all files updated, and it might be ASCII art of Ben's dog. A proper system would, for instance, have ways of communicating things like updated files other than stdout.
Like what? A refresher: I've barely used git and never with any hooks. I don't even know what this "improper" system is, let alone your or anyone else's vision of a "proper" system. All I'm getting is seemingly a bunch of whargarbl.
-
@boomzilla said in Software disenchantment:
Like what?
Well to give a basic example, if the post-commit hook rejected the commit, some text describing the reason why.
Right now there's zero formatting, so it's impossible for any GUI to guess at which bit of text that's spewed out is the reason the commit is rejected. (Assuming it's even present, there's no guarantee of that either.)
It's also impossible for any GUI to parse out:
- If the post-commit hook ran correctly at all (maybe it errored out because your internet is down, how would you know?)
- If the post-commit hook modified any files in the commit
- Whether the commit was accepted or rejected
- Whether the reason it was rejected is fixable by the person reading the message, or needs an admin to fix it (think of permissions errors for example)
And probably a dozen other things I can't think of right now.
-
@dkf said in Software disenchantment:
@topspin said in Software disenchantment:
computer science masturbation
The thing about CS masturbation is that it actually has an impact on what you can do. The non-fancy way of doing this all produced things like SCCS and CVS, whereas applying more theory allowed us to fix the crippling faults in those and lead to the better systems we have. Bad models can be patched over, but not completely hidden (because abstractions leak); good models enable far more with less effort, and don't cause quite such large disasters when they leak…
No disagreement from me there. That's why, if you look at the comic, "distributed graph theory model" still has the adjective "beautiful" to it.
The problem is that the abstraction here is very like and doesn't exactly fit the one the user wants to think in, so then you get to the part about "How do you use it?" "No idea."
-
@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?
Both.
FAYE KEDDIT:
likely.
-
@blakeyrat I agree that you have a point here that some restrictions on formatting would help with the parsing.
Still, I'd like to point out that your VS build system (and most others), which you probably use a lot more during the day than the VCS, also spews out text onto the build console. By convention, that text is formatted to let the IDE parse if it's a warning/error/info and what file/line, but any custom build steps can break that convention just as a custom git hook.
So while things could be improved, the current state isn't exactly without precedent.
-
@topspin said in Software disenchantment:
@blakeyrat I agree that you have a point here that some restrictions on formatting would help with the parsing.
If by "help with" you mean "make at all possible".
It's still a badly-designed feature. It really does need to be burned-down and rebuilt from scratch. Or just removed entirely.
@topspin said in Software disenchantment:
Still, I'd like to point out that your VS build system (and most others), which you probably use a lot more during the day than the VCS, also spews out text onto the build console.
And therefore...?
@topspin said in Software disenchantment:
By convention, that text is formatted to let the IDE parse if it's a warning/error/info and what file/line,
VS usually gets that from the Intellisense database, is my understanding. The only thing it parses out of the text spew is line numbers, so you can click a message and go to the line it refers to.
@topspin said in Software disenchantment:
but any custom build steps can break that convention just as a custom git hook. So while things could be improved, the current state isn't exactly without precedent.
Ok?
"Another product has the same flaw, therefore it's not a flaw!" Is that the argument you're building to here? Because if so, you're a fucking retard.
-
@blakeyrat said in Software disenchantment:
Ok?
"Another product has the same flaw, therefore it's not a flaw!" Is that the argument you're building to here? Because if so, you're a fucking retard.
"Another product has the same flaw, therefore your argument that git is the only product to ever come up with such an incredibly stupid design, ever, is void".
-
@topspin said in Software disenchantment:
therefore your argument that git is the only product to ever come up with such an incredibly stupid design, ever,
Quote me saying that. I fucking double-dog dare you.
Look I'm not responsible for the strange voices whispering in your ear, but you can't just make up arguments and then post them here as if I said them.
Is there a forum where I can debate with people who are, you know, not literally insane?
-
@blakeyrat Example
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.
Git is the only VCS I've used that gets me into the fix in the first place!
And the latte-sipping stereotype would write something way better than Git. (I mean, pretty much anybody would.)
I know you're going to say that's not related at all, but it sure sounds close enough.
-
@topspin Is that supposed to be an answer to my dare? Or what even is that?
-
@blakeyrat Yes.
-
@topspin said in Software disenchantment:
I know you're going to say that's not related at all, but it sure sounds close enough.
No, it really doesn't.
-
@blakeyrat said in Software disenchantment:
Is there a forum where I can debate with people who are, you know, not literally insane?
I don't think it's possible for all of the people in such a debate to be not-crazy. After all, you can't debate with people without you, yourself, being one of the people in the debate.
-
@HardwareGeek well, he said "debate with people", so technically, it's totally possible for a crazy person to be in debate with people of whom none are crazy. I mean, as long as that crazy person doesn't start debating with themselves.
-
@Gąska said in Software disenchantment:
You don't create branches with
git pushI do it every day.
git push -u origin MyBugNumber
Just createdMyBugNumberbranch in our Stash server.
-
@dcon you're like that guy from xkcd who used rapid CPU temperature spike as alias for ctrl key.
-
@aitap said in Software disenchantment:
just e-mails diffs and full ZIPs of source code with binaries.
Murder is justified.
-
@blakeyrat said in Software disenchantment:
@topspin said in Software disenchantment:
@blakeyrat I agree that you have a point here that some restrictions on formatting would help with the parsing.
If by "help with" you mean "make at all possible".
It's still a badly-designed feature. It really does need to be burned-down and rebuilt from scratch. Or just removed entirely.
@topspin said in Software disenchantment:
Still, I'd like to point out that your VS build system (and most others), which you probably use a lot more during the day than the VCS, also spews out text onto the build console.
And therefore...?
@topspin said in Software disenchantment:
By convention, that text is formatted to let the IDE parse if it's a warning/error/info and what file/line,
VS usually gets that from the Intellisense database, is my understanding. The only thing it parses out of the text spew is line numbers, so you can click a message and go to the line it refers to.
@topspin said in Software disenchantment:
but any custom build steps can break that convention just as a custom git hook. So while things could be improved, the current state isn't exactly without precedent.
Ok?
"Another product has the same flaw, therefore it's not a flaw!" Is that the argument you're building to here? Because if so, you're a fucking retard.
Still, I don't see the fundamental problem with git as regards the specific issue making it friendlier to GUIs. Hooks can be anything at all, so it's hard to parse their output. All right (still, I believe that this is not a totally insurmountable problem. Call me ignorant but I can think of many ways to at least limit the shitfuckery). What about the rest? Git's output is hard to parse? I doubt git's maintainers are especially against making git's output more consistent and reliable. Especially if you provide patches.
-
@admiral_p said in Software disenchantment:
I doubt git's maintainers are especially against making git's output more consistent and reliable. Especially if you provide patches.
Except there's this pesky thing called backwards compatibility. Because standard human interface and standard non-human interface are one snd the same, you now can't change any aspect of Git's output at all without risking to break hundreds of thousands CI scripts all around the world.
-
@admiral_p said in Software disenchantment:
(still, I believe that this is not a totally insurmountable problem. Call me ignorant but I can think of many ways to at least limit the shitfuckery)
It's not insurmountable. It is insurmountable in Git's implementation, because their implementation is pure retardness.
@admiral_p said in Software disenchantment:
What about the rest? Git's output is hard to parse? I doubt git's maintainers are especially against making git's output more consistent and reliable.
Except Git doesn't have a separate human and programmatic interface, so it's impossible to make any fixes to the human interface without also fucking over the programmatic interface. This is because it's written by incompetent clowns who have no fucking idea what they're doing.
@admiral_p said in Software disenchantment:
Especially if you provide patches.
We've been over that.
-
@Gąska said in Software disenchantment:
@admiral_p said in Software disenchantment:
I doubt git's maintainers are especially against making git's output more consistent and reliable. Especially if you provide patches.
Except there's this pesky thing called backwards compatibility. Because standard human interface and standard non-human interface are one snd the same, you now can't change any aspect of Git's output at all without risking to break hundreds of thousands CI scripts all around the world.
Really, if that is what's holding back git usability, I can't believe it's impossibly hard to extract the command line parsing and console output from git and put the rest in a libgit.so that gets called from the git binary.
Now git is just a simple stdin/stdout wrapper for libgit and you can call the latter from your program without parsing.
No massive effort required and no change to the command line interface.
-
@topspin said in Software disenchantment:
Really, if that is what's holding back git usability, I can't believe it's impossibly hard to extract the command line parsing and console output from git and put the rest in a libgit.so that gets called from the git binary.
Did you know about half of Git is written in Bash scripts?
-
@Gąska said in Software disenchantment:
Did you know about half of Git is written in Bash scripts?
I thought those were just wrappers for Perl scripts…
-
@dkf no, the Perl scripts are wrappers for Bash.
-
@topspin said in Software disenchantment:
Really, if that is what's holding back git usability, I can't believe it's impossibly hard to extract the command line parsing and console output from git and put the rest in a libgit.so that gets called from the git binary.
It's not. My understanding is that Git's code is already structured that way. They just refuse to do it.
-
@blakeyrat it's not. It's a multilingual mess with lots of ad-hoc design that never had and still doesn't have any consistent structure. There's a reason why you need entire Unix compatibility layer to run it on Windows.
-
@Gąska said in Software disenchantment:
@dkf no, the Perl scripts are wrappers for Bash.
It's
turtleswrappers all the way down!
-
@Gąska said in Software disenchantment:
@cvi said in Software disenchantment:
People prefer and value different things in almost all their interactions, so why would it be any different for software? What makes anybody think that they could design a perfect one-size-fits all one? Yeah, sure, one can make the UIs more discoverable and easier to learn, but when somebody starts to use said software on a regular basis, there will be some rough spots.
While I agree that it's very rare for people to agree which thing is the best in its category, and people will always find some flaws that not everybody sees as flaws, it's not hard to find things that people almost universally regard as bad - and when they do, it's very likely the thing is objectively bad. For example, it's almost impossible to find someone who doesn't think Fiat Multipla is ugly as hell.
And Git is the Multipla of the software world.
The thing with the Fiat Multipla is that apart from the utterly what the actual fuck?! looks of it, it'ś a decent enough family car. Roomy as hell on the inside. Not sure about the reliability though, with it being a Fiat.
-
@Carnage said in Software disenchantment:
Not sure about the reliability though, with it being a Fiat.
Better than a Rover.
