Software disenchantment

[sockpuppet7]

@MrL said in Software disenchantment:

No, most people use 'clone', 'commit', 'push', advanced super users use 'branch'. Everything beyond that is a 'don't touch' stuff. And there's a good reason for it: if you want to write software, get the shit done week after week, you don't want your tools to get in the way. You want things to be simple - write code, click a button and go home.

I use lots of bisect. Sometimes I use rebase, because for some weird reason rebase show less conflicts when I'm merging something I created 1 year ago, and just now it's going to be merged. (rebase shouldn't be different than merge for this, so I'm not sure if it's a good argument)

[HardwareGeek]

@Gąska said in Software disenchantment:

that the command to remove things from staging is the same command you use to revert bad merge (git reset).

This, IMHO, is a valid criticism of git. Git reset is too overloaded and too unintuitive.

[Bulb]

@MrL said in Software disenchantment:

@Bulb said in Software disenchantment:

… have to publish the work in TFS anyway…

I know such seniors. They divide into two groups. Clueless 'I heard git is great' and complicator gloves fetishists who actually like dealing with painful tools.

Notice I said have to publish the work in TFS anyway. And it still has the advantage for them to import into Git, do it in Git and export it back. For themselves. And then persuade others to use it. They don't have to, because they end up exporting into TFS. And most of them still does end up using Git. Do all of them like dealing with painful tools? Do you really believe that?

That's not unfortunate, but completely natural and desirable. Firstly, no normal person wants to acquire a PhD in handling a versioning tool. If you have any sense you learn your language(s), your platform(s) and business domain of your product. You concentrate your efforts on making better software, not on masturbatory sessions with overcomplicated tools. Secondly, simple branch-for-feature-merge-to-develop kind of works and the moment you start doing something more complicated, you're in a world of pain.

That's all nice and dandy until you make a mess of it. And you will, that's just life. Version control is there to help you get out of your fix. And so far, git has been much better at that than the other version control tools.

@MrL said in Software disenchantment:
No, you want your tool to help you. And git can, but you have to spend a bit of time understanding it. Every tool that can help you a lot requires that.

Help with what? From what I've seen in 9 out of every 10 projects none of 'powerful' features are ever used.

Things like @{5.minutes.ago}, master@{1}, merge --abort, gitk ..feature-branch, stage hunk/line in git gui, amend, log -S (a.k.a. pickaxe)… Those get used all the time, at least once the people know they are there. bisect comes in plenty handy too. Yes, there is also rebase -i, but that's mainly for when you want to be super-nice to the reviewer.

Note that none of that is about distributed, and much of it is not even about branches. They are about purely local functions, which is how git tfs is so much more useful TFS client than the one built into Visual Studio.

Hiew has better UI than anything I've seen for git. You can learn pretty much everything about its functionality from in-program help.

You can learn all of Git functionality from what the --help option on various command gives you. It is a long reading, because there is a lot of it.

[blakeyrat]

@Bulb said in Software disenchantment:

Every tool that can help you a lot requires that.

If the learning curve of Git were similar to, say, driving a car (a much more dangerous activity-- both for the driver and those around them), then I'd be fine with it.

But it's not. It's FAR harder and for no good reason.

Also your statement is bullshit, because good tools teach you how to use them as you use them. Git doesn't even attempt that. Good tools abstract the user UI from the programming UI. Git doesn't even attempt that. Good tools have feature-parity with the tools that came before. Git doesn't even attempt that.

Git attempts barely anything, and what it does attempt it fails at.

[Bulb]

@dkf said in Software disenchantment:

@Bulb said in Software disenchantment:

Shipping Is A Feature.

Arguably it's the primary feature of all. That which never ships, nobody gives a about.

Yes. The quote with a bit more context is:

Shipping is a feature. A really important feature. Your product must have it.

And really, the whole article is exact opposite of the one that started this thread — praising programmers who cut all corners and tie loose ends together with duct tape, but get the feature working, at passable quality, now. Because working shit today is simply more than perfect solution that might be ready on St. Dindus' day.

[blakeyrat]

@admiral_p said in Software disenchantment:

Unfortunately, Garageband is also very limited (as the name somewhat implies), and to make anything even remotely professional sounding (and it could be arguable that today the production is or at least can be more important than the music itself) you need to delve into digital audio theory, learn to use a super-complicated tool, each with their own WTFs, each packed with tons of features that most will never use (until you need them).

And yet all of them on a basic level have a window that's a (piano) keyboard and you can just punch at the keys with a mouse and get shit done with very little knowledge. All of those products, shitty as they are, are still easier to use than Git.

[blakeyrat]

@Bulb said in Software disenchantment:

That's all nice and dandy until you make a mess of it. And you will, that's just life. Version control is there to help you get out of your fix. And so far, git has been much better at that than the other version control tools.

Git is the only VCS I've used that gets me into the fix in the first place!

My first two years with Git were nothing but "detached head" 10 times a day. You quickly learned to NEVER depend on it doing ANYTHING right, but to do your actual coding in a backup of the repository so you could wipe-out the Git repo any time and restore your changes for when Git fucked up. Which it did. All the time.

(That all said, Git has become more reliable as time has gone on. But it hasn't gotten more usable. And it can't because it was written by idiots who don't understand that it's a bad idea to conflate a user interface with a scripting interface. If anybody ever comes up to you in a trade show or conference or something and says "I am a core developer of Git", please punch them in the face for me.)

EDIT: and that's not even to mention the MALFEATURES that make Git not fit-for-purpose. For example, implementing merge conflicts by shitting all over your code files (the source of many bugs over the years), or by allowing people to retroactively rewrite history (something NO source control product should allow, on a philosophical level).

@Bulb said in Software disenchantment:

You can learn all of Git functionality from what the --help option on various command gives you.

Bull-fucking-shit.

[boomzilla]

@blakeyrat said in Software disenchantment:

For example, implementing merge conflicts by shitting all over your code files (the source of many bugs over the years)

What sorts of bugs?

[blakeyrat]

@boomzilla goto fail; from Apple being the most famous one.

Also think about the sheer quantity of code in every compiler/IDE/developer tool that's there specifically to detect Git merge markers and try to handle them in some rational way. None of that code would have to exist if Git wasn't designed so stupidly.

[Bulb]

@Gąska said in Software disenchantment:

For example, git push doubles as the command to remove branches

So you want a special command for deleting remote branches when you both create and update them with git push

@Gąska said in Software disenchantment:

detached head is way too easy to invoke and can cause commits to be gone forever

It gives a big scary warning whenever you try to commit on a detached head. Unless you explicitly turn it off. Now with checking don't show again, but with setting an option.

Also, the commits are only gone forever if you don't remember to look for them in the next 90 days. Well, was it really an important commit if you don't miss it in three months

@Gąska said in Software disenchantment:

there's a mandatory step of staging between making a change and committing, which is PITA whenever you realize you don't want to commit something during writing of commit message

When you are writing the commit message, the unstaged and staged lists are there on the left, with the diff view above, so you just click the icons. And if you've already clicked commit (but not push), just switch the radio button to amend and you can still fix it. Because the most reasonable way to do this is from the GUI.

And if you do it on command line, the --amend is still there and documented in both short and long help (but yes, even the short help has 42 non-empty lines; the GUI is both simpler and easier here).

[Gąska]

@blakeyrat said in Software disenchantment:

@Bulb said in Software disenchantment:

That's all nice and dandy until you make a mess of it. And you will, that's just life. Version control is there to help you get out of your fix. And so far, git has been much better at that than the other version control tools.

Git is the only VCS I've used that gets me into the fix in the first place!

There's also SVN. You get into deep shit pretty much whenever you try anything more advanced with branches than creating one.

[boomzilla]

@blakeyrat I don't recall ever hearing that being blamed on git conflict resolution. I just did a quick search and didn't see anything blaming that either.

[Gąska]

@Bulb said in Software disenchantment:

@MrL said in Software disenchantment:

@Bulb said in Software disenchantment:

… have to publish the work in TFS anyway…

I know such seniors. They divide into two groups. Clueless 'I heard git is great' and complicator gloves fetishists who actually like dealing with painful tools.

Notice I said have to publish the work in TFS anyway.

Notice he said complicator gloves fetishists.

And it still has the advantage for them to import into Git, do it in Git and export it back. For themselves.

This advantage might be nothing more than "being Git".

And then persuade others to use it.

I've seen completely novice programmers who've got their first job in 2014 get persuaded into using Vim.

They don't have to, because they end up exporting into TFS.

Or don't they? I've worked in a similar setup - repo being SVN but some people using Git with git-svn plugin to commit to it - and I can tell you, once they started doing more advanced things with Git, it became literally impossible to work using pure SVN.

Do all of them like dealing with painful tools?

Do all of them get told by senior colleagues that Git is the best thing ever? I'm pretty sure all of them get told that. Do you think all of them would still be using Git if nobody told them to use Git to access their TFS repo?

Juniors being easily persuaded by seniors to use something tells you nothing about usability of that thing.

That's not unfortunate, but completely natural and desirable. Firstly, no normal person wants to acquire a PhD in handling a versioning tool. If you have any sense you learn your language(s), your platform(s) and business domain of your product. You concentrate your efforts on making better software, not on masturbatory sessions with overcomplicated tools. Secondly, simple branch-for-feature-merge-to-develop kind of works and the moment you start doing something more complicated, you're in a world of pain.

That's all nice and dandy until you make a mess of it. And you will, that's just life.

Only if you use Git.

@MrL said in Software disenchantment:
No, you want your tool to help you. And git can, but you have to spend a bit of time understanding it. Every tool that can help you a lot requires that.

Help with what? From what I've seen in 9 out of every 10 projects none of 'powerful' features are ever used.

Things like @{5.minutes.ago}

Sounds pretty useless. I can't imagine a situation where I don't know either the hash of the commit I want or how many version ago was the commit I want made, but know at what time it was made.

master@{1}

Referring to reflog entries relative to branch head? Are there any legitimate uses of that?

merge --abort

I only ever use it when I want to do git reset --hard but I get an error that I need to do git merge --abort first. Why can't it do that itself? I'm already removing all local changes anyway.

gitk ..feature-branch

Okay, that's kinda sorta useful... except gitk HEAD feature-branch is strictly more useful.

stage hunk/line in git gui

I have no clue what you said here.

amend

That's not very advanced either.

log -S (a.k.a. pickaxe)…

Never heard of it, and the manpage says "intended for the scripter’s use", which sounds like I, someone who doesn't write Git scripts, will never find it useful for anything.

Those get used all the time

I wonder just how often you write scripts for Git.

at least once the people know they are there.

And forget about everything else that's also there, apparently.

bisect comes in plenty handy too.

That I agree with. Though you need a very consistent one-step build system to use it effectively. Sadly, I've never had a chance.

Hiew has better UI than anything I've seen for git. You can learn pretty much everything about its functionality from in-program help.

You can learn all of Git functionality from what the --help option on various command gives you.

How exactly do I learn from --help alone that I can use git reflog to retrieve commits I've made with detached head after I've already checked out another branch?

It is a long reading, because there is a lot of it.

And it's because it's a long read why it's so hard to find things you actually need in it.

[admiral_p]

@blakeyrat said in Software disenchantment:

@admiral_p said in Software disenchantment:

Unfortunately, Garageband is also very limited (as the name somewhat implies), and to make anything even remotely professional sounding (and it could be arguable that today the production is or at least can be more important than the music itself) you need to delve into digital audio theory, learn to use a super-complicated tool, each with their own WTFs, each packed with tons of features that most will never use (until you need them).

And yet all of them on a basic level have a window that's a (piano) keyboard and you can just punch at the keys with a mouse and get shit done with very little knowledge. All of those products, shitty as they are, are still easier to use than Git.

Not really. It depends on what kind of DAW you use. Some are better suited for ITB loop-based music, others are more suited for complex compositions, maybe integrating lots of outboard hardware, others yet aim at replicating the workflow of an old-school console, etc. Some DAWs are really bad at MIDI, others are really bad at being used like you'd use a tape recorder. The sheer amount of features makes it impossible to make such features discoverable, so you have to RTFM and have a decent understanding of what you're trying to do. Professional software is supposed to be used by professionals (duh?) who shouldn't expect to use it like you'd drive a car, but like an airliner. If you want simpler tools, there is a plethora of alternatives. Maybe what you're really mad at is everybody using git even when you don't need all its features (design issues notwithstanding; nothing is perfect, and I doubt anybody believes git is, not even their creators). And anyway, since you fucking hate using the tool but, supposedly, you’re forced to use it, why don't you fucking propose a patch/UI redesign or even just a debate? It's open source after all.

[Gąska]

@Bulb said in Software disenchantment:

@Gąska said in Software disenchantment:

For example, git push doubles as the command to remove branches

So you want a special command for deleting remote branches when you both create and update them with git push

You don't create branches with git push. You create them with git branch. And you update them with git commit. git push only sends your local changes to the branch to the remote repo, just like git pull downloads remote changes in the branch to your local repo. This is how normal people reason about branches and version control in general. It works perfectly up until the point when you do git branch --remove and want your local change to be uploaded to remote. Yes, I know that the problem comes from the fact the branch in your local copy and the branch on remote are actually two different branches. But the problem with Git is that you HAVE TO be aware of that to make any sense of it.

This problem is very specific to Git. I don't know of any other VCS where people have similar problems because a single branch is actually multiple branches that have special magic attached to them to make them behave as one for almost every purpose, except this one very specific and very common use case.

@Gąska said in Software disenchantment:

detached head is way too easy to invoke and can cause commits to be gone forever

It gives a big scary warning whenever you try to commit on a detached head. Unless you explicitly turn it off. Now with checking don't show again, but with setting an option.

Must be a new adittion. Last time I checked, it only gave you a warning on initial checkout, and a much smaller warning on git status.

Also, the commits are only gone forever if you don't remember to look for them in the next 90 days.

Only if you know about reflog. Most users start without knowledge of reflog, up until the first time they almost lose data because of commits to detached head. And every seasoned Git user knows about reflog.

@Gąska said in Software disenchantment:

there's a mandatory step of staging between making a change and committing, which is PITA whenever you realize you don't want to commit something during writing of commit message

When you are writing the commit message, the unstaged and staged lists are there on the left, with the diff view above, so you just click the icons. And if you've already clicked commit (but not push), just switch the radio button to amend and you can still fix it.

Wait what? Are you talking about Git GUI or something? I was talking about the only sensible way to work with Git - through CLI.

Because the most reasonable way to do this is from the GUI.

Except that every single Git GUI is absolutely awful, as you said yourself just yesterday.

And if you do it on command line, the --amend is still there

No, you don't get it. I'm not saying about making changes after I've committed. I'm saying about rolling back changes before I commit. Yes, I can do this by making a commit that I'm going to throw away in two seconds, rolling back the changes and then amending the commit, thus avoiding having to deal with stage, but this just shows how awful this whole stage thing is if it's easier to just make fake commits and alter them than to unstage one file.

[blakeyrat]

@admiral_p This is another lecture about "if it's professional software it doesn't have to be easy to use!" which is the wrongest thinking in software development, and fuck you for even having that opinion, much less sharing it with others.

No, it's not true, it's not accurate, and it's not desirable.

You're just excusing lazy developers who wrote their program in the era of "dancing bear"^* software and have gone decades without bothering to do any kind of UX work because, once again: they are lazy.

^*) The term from Alan Cooper for software that was written back when the exciting thing about it was that the computer could do the task at all, and there was zero consideration for whether the computer is doing it in the best way. The metaphor is that if a circus has a dancing bear, the interesting thing isn't that the bear is dancing well, the exciting thing is that the bear can dance at all.

[admiral_p]

@blakeyrat said in Software disenchantment:

@admiral_p This is another lecture about "if it's professional software it doesn't have to be easy to use!" which is the wrongest thinking in software development, and fuck you for even having that opinion, much less sharing it with others.

No, it's not true, it's not accurate, and it's not desirable.

You're just excusing lazy developers who wrote their program in the era of "dancing bear"^* software and have gone decades without bothering to do any kind of UX work because, once again: they are lazy.

^*) The term from Alan Cooper for software that was written back when the exciting thing about it was that the computer could do the task at all, and there was zero consideration for whether the computer is doing it in the best way. The metaphor is that if a circus has a dancing bear, the interesting thing isn't that the bear is dancing well, the exciting thing is that the bear can dance at all.

If it's professional software, it doesn't have to be hard to use, but sometimes there is only so much design and pondering can do. Of course, you can make some things easier. Anyway as I said, you have legitimate misgivings about git? Do you have any practical proposals? Then make a patch already. It's in your self-interest, because you yourself said that you are forced to use the damn thing and you're either going to wait for somebody to feel the same yet putting some effort in it instead of whining, or you're going to keep on whining until something better (quality/price ratio) comes along. If it's a fundamental design issue, then have you ever stopped to think that maybe it's you who doesn't get or like the design? Because millions of developers don't seem to be too worked up about it.

[Gąska]

@admiral_p said in Software disenchantment:

@blakeyrat said in Software disenchantment:

@admiral_p This is another lecture about "if it's professional software it doesn't have to be easy to use!" which is the wrongest thinking in software development, and fuck you for even having that opinion, much less sharing it with others.

No, it's not true, it's not accurate, and it's not desirable.

You're just excusing lazy developers who wrote their program in the era of "dancing bear"^* software and have gone decades without bothering to do any kind of UX work because, once again: they are lazy.

^*) The term from Alan Cooper for software that was written back when the exciting thing about it was that the computer could do the task at all, and there was zero consideration for whether the computer is doing it in the best way. The metaphor is that if a circus has a dancing bear, the interesting thing isn't that the bear is dancing well, the exciting thing is that the bear can dance at all.

If it's professional software, it doesn't have to be hard to use, but sometimes there is only so much design and pondering can do.

Almost all software is very far from that point. Almost every tool I personally use - and I mostly use the same stuff as everyone else - has some obvious pain points that remind you of themselves almost everyday that could be completely alleviated with just a bit more time spent on proper design, with no drawbacks.

Anyway as I said, you have legitimate misgivings about git? Do you have any practical proposals? Then make a patch already.

Fuck you and your "can't criticize free things" attitude. It's because of people like you why open source can't have nice things.

[dkf]

@admiral_p said in Software disenchantment:

And anyway, since you fucking hate using the tool but, supposedly, you’re forced to use it, why don't you fucking propose a patch/UI redesign or even just a debate?

He doesn't want to fix it. He wants to grumble about it.

[dkf]

@Gąska said in Software disenchantment:

Almost every tool I personally use - and I mostly use the same stuff as everyone else - has some obvious pain points that remind you of themselves almost everyday that could be completely alleviated with just a bit more time spent on proper design, with no drawbacks.

If you think it is easy, get coding. I don't think it is particularly easy, at least not enough to get over my innate laziness, so don't expect a vast amount of assistance from me, but I'm totally not the guy holding you back from achieving your software vision. But I'd note that often things that seem obvious to one person will appear very not obvious to someone else; even if you create your ideal interface, it might not appeal to as many other people as you think.

And you'll probably need to understand what's really going on in order to get it right. ;)

[admiral_p]

@Gąska said in Software disenchantment:

@admiral_p said in Software disenchantment:

@blakeyrat said in Software disenchantment:

@admiral_p This is another lecture about "if it's professional software it doesn't have to be easy to use!" which is the wrongest thinking in software development, and fuck you for even having that opinion, much less sharing it with others.

No, it's not true, it's not accurate, and it's not desirable.

You're just excusing lazy developers who wrote their program in the era of "dancing bear"^* software and have gone decades without bothering to do any kind of UX work because, once again: they are lazy.

^*) The term from Alan Cooper for software that was written back when the exciting thing about it was that the computer could do the task at all, and there was zero consideration for whether the computer is doing it in the best way. The metaphor is that if a circus has a dancing bear, the interesting thing isn't that the bear is dancing well, the exciting thing is that the bear can dance at all.

If it's professional software, it doesn't have to be hard to use, but sometimes there is only so much design and pondering can do.

Almost all software is very far from that point. Almost every tool I personally use - and I mostly use the same stuff as everyone else - has some obvious pain points that remind you of themselves almost everyday that could be completely alleviated with just a bit more time spent on proper design, with no drawbacks.

Anyway as I said, you have legitimate misgivings about git? Do you have any practical proposals? Then make a patch already.

Fuck you and your "can't criticize free things" attitude. It's because of people like you why open source can't have nice things.

You can criticise all you want, but it's just whining at the end of the day, until somebody doesn't actually do something about it. Mind you, you don't necessarily have to volunteer your free time to fix git (or whatever), but if you think that your work life (and therefore your life in general) could benefit, at least weigh in on the (official) debate. Frankly with whatever tool I have to use I'm very Zen-like about their weaknesses. As long as it doesn't kill me...

[dkf]

@admiral_p said in Software disenchantment:

Frankly with whatever tool I have to use I'm very Zen-like about their weaknesses. As long as it doesn't kill me...

You mean you might be OK with using an old copy of Microsoft Visual SourceSafe? I think you'll wish to reconsider your acceptance threshold to be at least a bit higher…

[cvi]

@dkf said in Software disenchantment:

But I'd note that often things that seem obvious to one person will appear very not obvious to someone else; even if you create your ideal interface, it might not appeal to as many other people as you think.

Really, this.

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.

I personally consider it important that I have a chance to fix the worst rough spots. After all, the computer is a tool, and I'd rather have the tool adapt to my needs than the other way around (the other way around is dumb).

[Bulb]

@Gąska said in Software disenchantment:

And it still has the advantage for them to import into Git, do it in Git and export it back. For themselves.

This advantage might be nothing more than "being Git".

No. This advantage is not fucking up the work in progress when the next update creates a conflict and the resolution does not go right. This advantage is being able to keep the shelveset from a colleague separate from their own work. This advantage is being able to checkin a bugfix extracted from a work in progress on the same files. This advantage is being able to cooperate on changes with a colleague when the fucked up structure of the TFS project makes creating a feature branch there a major pain in the arse. And sometimes also being nice to the reviewer and not bother them with several experimental changes and their later reverts.

[Gąska]

@dkf said in Software disenchantment:

@Gąska said in Software disenchantment:

Almost every tool I personally use - and I mostly use the same stuff as everyone else - has some obvious pain points that remind you of themselves almost everyday that could be completely alleviated with just a bit more time spent on proper design, with no drawbacks.

If you think it is easy, get coding.

I don't wish to maintain my own Git fork, and Git crew don't wish to accept my patch for making git branch --delete mark the branch for deletion in upstream on next git push.

And why is it my responsibility to fix tool someone else made? Why can't I point out bad design decisions in other people's works without feeling obliged to fix them myself? Is that specific to open source software, or do you have the same attitude for literary and movie critics? "Don't like how they treat Banners in Infinity War? Shoot your own movie goddammit and stop whining!"

See my previous post to what I think of this kind of attitude.

[Gąska]

@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 This is another lecture about "if it's professional software it doesn't have to be easy to use!" which is the wrongest thinking in software development, and fuck you for even having that opinion, much less sharing it with others.

No, it's not true, it's not accurate, and it's not desirable.

You're just excusing lazy developers who wrote their program in the era of "dancing bear"^* software and have gone decades without bothering to do any kind of UX work because, once again: they are lazy.

^*) The term from Alan Cooper for software that was written back when the exciting thing about it was that the computer could do the task at all, and there was zero consideration for whether the computer is doing it in the best way. The metaphor is that if a circus has a dancing bear, the interesting thing isn't that the bear is dancing well, the exciting thing is that the bear can dance at all.

If it's professional software, it doesn't have to be hard to use, but sometimes there is only so much design and pondering can do.

Almost all software is very far from that point. Almost every tool I personally use - and I mostly use the same stuff as everyone else - has some obvious pain points that remind you of themselves almost everyday that could be completely alleviated with just a bit more time spent on proper design, with no drawbacks.

Anyway as I said, you have legitimate misgivings about git? Do you have any practical proposals? Then make a patch already.

Fuck you and your "can't criticize free things" attitude. It's because of people like you why open source can't have nice things.

You can criticise all you want, but it's just whining at the end of the day, until somebody doesn't actually do something about it.

So what if it's just whining? Does it make my criticism less valid?

Mind you, you don't necessarily have to volunteer your free time to fix git (or whatever), but if you think that your work life (and therefore your life in general) could benefit, at least weigh in on the (official) debate.

Didn't you just call all debate that doesn't result in stuff getting changed "just whining"? There's nowhere I can voice my opinions that will actually affect how the Git developers design Git. It's because there are fundamental philosophical differences between me and Git developers that makes them not even consider the possibility of making git reset command less convoluted. There's nothing I can do to change how Git behaves. No, not even writing my own patches. Because they're never going to end up in upstream Git source, and it'll take tremendous amount of work to maintain my own fork - and to distribute it among the 150 people I share repositories with, and convince them to use it over the vanilla Git, and to make sure they actually use it over the vanilla Git (there's about 30 ways one might accidentally use a different version of a program than the one they intended to use).

Frankly with whatever tool I have to use I'm very Zen-like about their weaknesses. As long as it doesn't kill me...

You know what wouldn't kill you either? Not being able to make branches. Would you be okay using VCS that doesn't support branches?

Whining is the catalyst of progress. Complacency results in mediocrity. Sure, it's possible to live in mediocrity, but I'd rather live in progress. And I mean progress, not changes for the sake of changes. Actual progress that makes life better. It can't exist without people whining about things that are bad. Whether it's politics or software development.

[Gąska]

@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.

[Tsaukpaetra]

@Gąska said in Software disenchantment:

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.

OMG I found my new favorite alien car!

[admiral_p]

@Gąska said in Software disenchantment:

@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 This is another lecture about "if it's professional software it doesn't have to be easy to use!" which is the wrongest thinking in software development, and fuck you for even having that opinion, much less sharing it with others.

No, it's not true, it's not accurate, and it's not desirable.

You're just excusing lazy developers who wrote their program in the era of "dancing bear"^* software and have gone decades without bothering to do any kind of UX work because, once again: they are lazy.

^*) The term from Alan Cooper for software that was written back when the exciting thing about it was that the computer could do the task at all, and there was zero consideration for whether the computer is doing it in the best way. The metaphor is that if a circus has a dancing bear, the interesting thing isn't that the bear is dancing well, the exciting thing is that the bear can dance at all.

If it's professional software, it doesn't have to be hard to use, but sometimes there is only so much design and pondering can do.

Almost all software is very far from that point. Almost every tool I personally use - and I mostly use the same stuff as everyone else - has some obvious pain points that remind you of themselves almost everyday that could be completely alleviated with just a bit more time spent on proper design, with no drawbacks.

Anyway as I said, you have legitimate misgivings about git? Do you have any practical proposals? Then make a patch already.

Fuck you and your "can't criticize free things" attitude. It's because of people like you why open source can't have nice things.

You can criticise all you want, but it's just whining at the end of the day, until somebody doesn't actually do something about it.

So what if it's just whining? Does it make my criticism less valid?

No, but it makes it cheaper.

Mind you, you don't necessarily have to volunteer your free time to fix git (or whatever), but if you think that your work life (and therefore your life in general) could benefit, at least weigh in on the (official) debate.

Didn't you just call all debate that doesn't result in stuff getting changed "just whining"? There's nowhere I can voice my opinions that will actually affect how the Git developers design Git. It's because there are fundamental philosophical differences between me and Git developers that makes them not even consider the possibility of making git reset command less convoluted. There's nothing I can do to change how Git behaves. No, not even writing my own patches. Because they're never going to end up in upstream Git source, and it'll take tremendous amount of work to maintain my own fork - and to distribute it among the 150 people I share repositories with, and convince them to use it over the vanilla Git, and to make sure they actually use it over the vanilla Git (there's about 30 ways one might accidentally use a different version of a program than the one they intended to use).

Then maybe you should use another VCS, if given a choice? If you have no choice, you can always point out how Git is a pain to use and propose a different system (of which there are plenty).

Frankly with whatever tool I have to use I'm very Zen-like about their weaknesses. As long as it doesn't kill me...

You know what wouldn't kill you either? Not being able to make branches. Would you be okay using VCS that doesn't support branches?

I don't program for a living. I have other s in my field. I try to convince my superiors to switch to something better, if that fails, what can you do?

Whining is the catalyst of progress. Complacency results in mediocrity. Sure, it's possible to live in mediocrity, but I'd rather live in progress. And I mean progress, not changes for the sake of changes. Actual progress that makes life better. It can't exist without people whining about things that are bad. Whether it's politics or software development.

Yeah, all right, but to actually progress, somebody must do something about it.

[Gąska]

@Bulb said in Software disenchantment:

@Gąska said in Software disenchantment:

And it still has the advantage for them to import into Git, do it in Git and export it back. For themselves.

This advantage might be nothing more than "being Git".

No. This advantage is not fucking up the work in progress when the next update creates a conflict and the resolution does not go right. This advantage is being able to keep the shelveset from a colleague separate from their own work. This advantage is being able to checkin a bugfix extracted from a work in progress on the same files. This advantage is being able to cooperate on changes with a colleague when the fucked up structure of the TFS project makes creating a feature branch there a major pain in the arse. And sometimes also being nice to the reviewer and not bother them with several experimental changes and their later reverts.

Wow, TFS sucks. From this description, it sounds like it sucks so much it's unbelievable that Microsoft would even release such piece of shit, yes, even the Microsoft that released Windows 8. Since I have no direct experience with TFS, and taking into consideration that you're Git advocate, I'm going to take your account of this unbelievable clusterfuck with a grain on salt, and let the other side respond first.

So I'm calling our resident TFS expert and advocate, @blakeyrat, to tell us just how wrong @Bulb is in his description of TFS, and why none of the above is a problem with a properly configured, properly used TFS.

[Gąska]

@admiral_p said in Software disenchantment:

@Gąska said in Software disenchantment:

@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 This is another lecture about "if it's professional software it doesn't have to be easy to use!" which is the wrongest thinking in software development, and fuck you for even having that opinion, much less sharing it with others.

No, it's not true, it's not accurate, and it's not desirable.

You're just excusing lazy developers who wrote their program in the era of "dancing bear"^* software and have gone decades without bothering to do any kind of UX work because, once again: they are lazy.

^*) The term from Alan Cooper for software that was written back when the exciting thing about it was that the computer could do the task at all, and there was zero consideration for whether the computer is doing it in the best way. The metaphor is that if a circus has a dancing bear, the interesting thing isn't that the bear is dancing well, the exciting thing is that the bear can dance at all.

If it's professional software, it doesn't have to be hard to use, but sometimes there is only so much design and pondering can do.

Almost all software is very far from that point. Almost every tool I personally use - and I mostly use the same stuff as everyone else - has some obvious pain points that remind you of themselves almost everyday that could be completely alleviated with just a bit more time spent on proper design, with no drawbacks.

Anyway as I said, you have legitimate misgivings about git? Do you have any practical proposals? Then make a patch already.

Fuck you and your "can't criticize free things" attitude. It's because of people like you why open source can't have nice things.

You can criticise all you want, but it's just whining at the end of the day, until somebody doesn't actually do something about it.

So what if it's just whining? Does it make my criticism less valid?

No, but it makes it cheaper.

What does "cheaper" even mean in this context? Usually it means "less valid", but you've explicitly said it's not that.

Mind you, you don't necessarily have to volunteer your free time to fix git (or whatever), but if you think that your work life (and therefore your life in general) could benefit, at least weigh in on the (official) debate.

Didn't you just call all debate that doesn't result in stuff getting changed "just whining"? There's nowhere I can voice my opinions that will actually affect how the Git developers design Git. It's because there are fundamental philosophical differences between me and Git developers that makes them not even consider the possibility of making git reset command less convoluted. There's nothing I can do to change how Git behaves. No, not even writing my own patches. Because they're never going to end up in upstream Git source, and it'll take tremendous amount of work to maintain my own fork - and to distribute it among the 150 people I share repositories with, and convince them to use it over the vanilla Git, and to make sure they actually use it over the vanilla Git (there's about 30 ways one might accidentally use a different version of a program than the one they intended to use).

Then maybe you should use another VCS, if given a choice?

And never mention to anyone the reasons why I chose another VCS over Git?

If you have no choice, you can always point out how Git is a pain to use and propose a different system (of which there are plenty).

I do it all the time. Mercurial has most of the same capabilities as Git and is much harder to shoot yourself in the foot with. Or if we wait a few more years, Pijul, which offers a groundbreaking new perspective on merging and conflict resolution.

Frankly with whatever tool I have to use I'm very Zen-like about their weaknesses. As long as it doesn't kill me...

You know what wouldn't kill you either? Not being able to make branches. Would you be okay using VCS that doesn't support branches?

I don't program for a living.

Oh, right. I always forget that you have no direct experience with things you're talking about.

I have other s in my field. I try to convince my superiors to switch to something better, if that fails, what can you do?

You can set up a blog and whine there about how broken education is. You can make posts on Reddit or whatever Italian site there is and whine there about how broken education system is. You can start/join a Facebook group dedicated to whining about how broken education system is. If you feel particularly strong about it and have enough free time, you might even become a serious political activist for whom whining about how broken education system is basically becomes a second job. It's a popular, time tested method of pushing for changes that make education system suck less. All you need is get enough people to whine instead of quietly accepting their faith of zenning the hell out of broken education system.

Whining is the catalyst of progress. Complacency results in mediocrity. Sure, it's possible to live in mediocrity, but I'd rather live in progress. And I mean progress, not changes for the sake of changes. Actual progress that makes life better. It can't exist without people whining about things that are bad. Whether it's politics or software development.

Yeah, all right, but to actually progress, somebody must do something about it.

First they need to gain support. You ain't going to gain support without being loud about the issue. In fact, popular support is the only reason why the IT industry hasn't ditched Git completely yet. There are alternatives. It's just people don't think these alternatives bring enough improvement to warrant change. Note that this is a very different problem from alternatives not bringing enough improvement.

[blakeyrat]

@admiral_p said in Software disenchantment:

If it's professional software, it doesn't have to be hard to use, but sometimes there is only so much design and pondering can do.

Perhaps; now convince me Git even fucking tried.

@admiral_p said in Software disenchantment:

Because millions of developers don't seem to be too worked up about it.

A lot of people eat at McDonalds too.

@dkf said in Software disenchantment:

He doesn't want to fix it. He wants to grumble about it.

No. I don't want to write fucking C. Test in Linux. Or have the kind of annoying conversations I imagine doing a pull request to Git would involve having.

@admiral_p said in Software disenchantment:

Mind you, you don't necessarily have to volunteer your free time to fix git (or whatever), but if you think that your work life (and therefore your life in general) could benefit, at least weigh in on the (official) debate.

If the people in charge of Git don't think their product is shitty now, it's fucking hopeless. There's nothing you could do to get those delusional motherfuckers within 500 miles of "reality".

[blakeyrat]

@Gąska said in Software disenchantment:

"Don't like how they treat Banners in Infinity War? Shoot your own movie goddammit and stop whining!"

Git aside, seriously, what the fuck is with the Hulk not appearing.

Spoiler I guess. But sheesh, that was a disappointment.

[blakeyrat]

@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:

It's a fucking super model compared to that Fiat.

[sockpuppet7]

@blakeyrat said in Software disenchantment:

Spoiler

Edit: thinking again, it didn't ruin anything desirable for when I watch it anyway

[Tsaukpaetra]

@blakeyrat said in Software disenchantment:

@Gąska said in Software disenchantment:

"Don't like how they treat Banners in Infinity War? Shoot your own movie goddammit and stop whining!"

Git aside, seriously, what the fuck is with the Hulk not appearing.

Spoiler I guess. But sheesh, that was a disappointment.

I think he was on a sabbatical. Or something.

[blakeyrat]

@sockpuppet7 I figured it's been long enough that anybody who hasn't seen it isn't gonna.

[Bulb]

@Gąska said in Software disenchantment:

@Bulb said in Software disenchantment:

Things like @{5.minutes.ago}

Sounds pretty useless. I can't imagine a situation where I don't know either the hash of the commit I want or how many version ago was the commit I want made, but know at what time it was made.

Oh, but it does not say anything about when the commit was made. It refers to a commit that was checked out as of 5 minutes ago. Probably before a pull or a rebase or a reset or something. Or you can use any other time, of course.

master@{1}

Referring to reflog entries relative to branch head? Are there any legitimate uses of that?

To a reflog of a branch head. Many operations write to the HEAD reflog, but only operations that actually move the branch head write to the reflog of that. Keeping track of the indices to HEAD reflog is almost impossible, but for specific branch they are sometimes useful.

merge --abort

I only ever use it when I want to do git reset --hard but I get an error that I need to do git merge --abort first. Why can't it do that itself? I'm already removing all local changes anyway.

Hm, not sure, but I always prefer the specific commands over hard reset. Hard reset is one of the few actually destructive commands, so that's why.

gitk ..feature-branch

Okay, that's kinda sorta useful... except gitk HEAD feature-branch is strictly more useful.

If the branches are long and have subbranches, showing only the commits on one or the other side comes in handy.

stage hunk/line in git gui

I have no clue what you said here.

The entries in the context menu of the GUI. Extremely useful.

amend

That's not very advanced either.

log -S (a.k.a. pickaxe)…

Never heard of it, and the manpage says "intended for the scripter’s use", which sounds like I, someone who doesn't write Git scripts, will never find it useful for anything.

Ok, you got me. Git documentation sucks. I don't even …

log -G and -S options are about the most useful feature when you are trying to find where that weird bit of code comes from so you can glean something about its purpose. The documentation is just silly. It is also silly that the feature is called ‘pickaxe’ in all descriptions and discussions, but the only mention of pickaxe is in the name of --pickaxe-regex option and the description of it's meaning is pretty confusing too.

Those get used all the time

I wonder just how often you write scripts for Git.

NONE of the above features is used from scripts or mainly from scripts.

How exactly do I learn from --help alone that I can use git reflog to retrieve commits I've made with detached head after I've already checked out another branch?

It is a long reading, because there is a lot of it.

And it's because it's a long read why it's so hard to find things you actually need in it.

Not really. It's because whoever wrote it wrote a pretty good reference, but sucked at actually explaining things in logical order, so the relevant bits are burried somewhere deep in a lot of text that absolutely talks about something completely different.

It does surprise me though that, given the big companies including Microsoft using it, there is not much other documentation available to fill in.

[Gąska]

@Bulb said in Software disenchantment:

@Gąska said in Software disenchantment:

@Bulb said in Software disenchantment:

Things like @{5.minutes.ago}

Sounds pretty useless. I can't imagine a situation where I don't know either the hash of the commit I want or how many version ago was the commit I want made, but know at what time it was made.

Oh, but it does not say anything about when the commit was made. It refers to a commit that was checked out as of 5 minutes ago. Probably before a pull or a rebase or a reset or something. Or you can use any other time, of course.

Sounds even more useless then. The only use case I can think of is if you want to do git reflog but don't know git reflog.

master@{1}

Referring to reflog entries relative to branch head? Are there any legitimate uses of that?

To a reflog of a branch head. Many operations write to the HEAD reflog, but only operations that actually move the branch head write to the reflog of that. Keeping track of the indices to HEAD reflog is almost impossible, but for specific branch they are sometimes useful.

For example?

merge --abort

I only ever use it when I want to do git reset --hard but I get an error that I need to do git merge --abort first. Why can't it do that itself? I'm already removing all local changes anyway.

Hm, not sure, but I always prefer the specific commands over hard reset. Hard reset is one of the few actually destructive commands, so that's why.

It also leaves you with (more or less) consistent prior state (hopefully) identical to when you made your last (or given) commit. A very important concept if you're not Git expert and tend to mistake one command for another or mess up the order of parameters. If I'm aborting a merge, 99 out of 100 times I also want to revert all files to how they were before merge - git merge --abort doesn't do that.

gitk ..feature-branch

Okay, that's kinda sorta useful... except gitk HEAD feature-branch is strictly more useful.

If the branches are long and have subbranches, showing only the commits on one or the other side comes in handy.

If you said git log, then you'd have a point. But you said gitk, which is a GUI tool that lists commits in a listbox with scrollbar, newest commits first. There's literally no downside to using gitk HEAD feature-branch over gitk ..feature-branch.

stage hunk/line in git gui

I have no clue what you said here.

The entries in the context menu of the GUI. Extremely useful.

I still have no clue what these do.

log -S (a.k.a. pickaxe)…

Never heard of it, and the manpage says "intended for the scripter’s use", which sounds like I, someone who doesn't write Git scripts, will never find it useful for anything.

Ok, you got me. Git documentation sucks. I don't even …

At least you admitted it. Your previous posts made it sound like Git help texts and manpages are high quality material that lets you learn everything there is to learn about Git very easily.

log -G and -S options are about the most useful feature when you are trying to find where that weird bit of code comes from so you can glean something about its purpose.

So it's like blame on steroids? Ok, that sounds pretty useful in some very specific situations, once every couple of years. Usually regular git blame is enough.

It does surprise me though that, given the big companies including Microsoft using it, there is not much other documentation available to fill in.

There's entirety of StackOverflow, as well as millions of random blog posts explaining various common and less common features. That's how I learned Git myself. The only case when I use git --help is when I know exactly what a command does and exactly how to use it, but don't remember exact argument names. To actually get help, I always google first.

[Cursorkeys]

@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:

[Gąska]

@Cursorkeys at least it has conventionally placed headlamps.

[dkf]

@Gąska said in Software disenchantment:

And why is it my responsibility to fix tool someone else made?

Because you're the one seeing it as a problem when the other people don't.

[Cursorkeys]

@Gąska said in Software disenchantment:

@Cursorkeys at least it has conventionally placed headlamps.

True, the rest of it should count as a declaration of war though.

We did come up with the Nissan Cube, but I think that should get a 'so bad it's good' mention, it always makes me laugh anyway:

It's a bit like the old Skyvan, aka 'you forgot to take your plane out of the box it came in':

[dkf]

@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.

[Gąska]

@dkf said in Software disenchantment:

@Gąska said in Software disenchantment:

And why is it my responsibility to fix tool someone else made?

Because you're the one seeing it as a problem when the other people don't.

I still don't see how that makes it my responsibility to fix it. I could understand if you said it's not worth to change thing only one person sees as a problem. But you said that I SHOULD fix it MYSELF. With the implication that if I'm not willing to do it myself, it's not a real issue even for me.

[admiral_p]

@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.

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.

[Jaloopa]

@admiral_p said in Software disenchantment:

you have legitimate misgivings about git? Do you have any practical proposals? Then make a patch already

There aren't many practical proposals that can be made to fix a series of bad decisions in the core design of the product

[Jaloopa]

@Bulb said in Software disenchantment:

the fucked up structure of the TFS project makes creating a feature branch there a major pain in the arse

TIL right click, branching and merging, branch is a major pain in the arse

[Jaloopa]

@admiral_p said in Software disenchantment:

If you have no choice, you can always point out how Git is a pain to use and propose a different system (of which there are plenty).

When there was discussion at my last job about switching to Git, I was one of the strongest voices about how there was nothing wrong with our current TFS solution, Git was a whole new learning curve for tens of developers who were proficient with everything they needed to do in TFS, and that there was no rationale given as to how Git would improve anything and be worth the pain of switching, beyond "look, some other people use it". When it started to look like they might switch anyway was when I started looking for a new job. In the end the proposal fell through but I already had an interview for my current place on the table at that point

[Jaloopa]

@Bulb said in Software disenchantment:

pretty good reference

@Bulb said in Software disenchantment:

sucked at actually explaining things

These are mutually incompatible