Hey SourceTree, I WANNA DELETE MY LOCAL BRANCH MESSINESS!
-
@FrostCat said:
2015 does. Of the 5 highlighted rows, only the checked one will be added to the project if I hit OK.
Annoyed because I posted first?
-
@abarker said:
@FrostCat said:
2015 does. Of the 5 highlighted rows, only the checked one will be added to the project if I hit OK.
Annoyed because I posted first?
No, expressing my rage at that particular behavior in VS 2013+.
-
No, expressing my rage at that particular behavior in VS 2013+.
That behavior isn't the problem. The dialog isn't an "Add References" dialog, it's a "Modify References" dialog. The selected items aren't the ones to be added, they are the ones that will be references when you click "OK". To remove a reference, open that dialog and uncheck a currently checked reference. Highlighting has sane behavior - you can highlight any number of items, and set them all or clear them all from the context menu.
So, it isn't the behavior that's broken, it's the name.
-
@riking and I didn't start a rant about the problem in SourceTree either. I assume you ran into the problem in VS before you encountered it in SourceTree.
I guess I need to spell it out: I don't think this is about the the listboxes. I think if this were in some program where this was the only problem you had with it, we wouldn't hear a word from you about it. This just sound like some more of your git bashing to me.
This is a horrible defense. If an argument is valid, it doesn't weaken the argument to show other cases where the argument is more valid or where the author doesn't claim the argument to be valid. I despise the statement "That's the pot calling the kettle black" because the pot's blackness has no bearing on the kettle's blackness. A black pot's claim of the kettle being black is not weaker than a white pot's claim of the same.
-
-
Every time I complain about Git having no decent UIs, someone comes into the thread and recommends I use SourceTree as a "good" Git UI. It's happened several times.
In the land of the blind one-eye is king?
-
ProTip: Branches are just tiny files inside .git/refs/heads
Just delete the files. You can do it with File Explorer for instance and it probably lets you select them in a sane way you already know/like.
-
Did you ever read that story?
Those blind guys kicked his ass.
-
-
ProTip: Branches are just tiny files inside .git/refs/heads
Just delete the files. You can do it with File Explorer for instance and it probably lets you select them in a sane way you already know/like.
Not sure if ironic or really meant to give the thermonuclear solution.
Filed under: Hey SourceTree, I WANNA UNDO THE DELETE OF MY LOCAL BRANCHE MESSINESS!
-
BOXING IN WATER BLINDFOLDED
How can the referee impartially judge them if he isn't blindfolded too?
-
Easy, just restore them from the trash. You are using the trash, right?
-
It's not that thermonuclear. Deleting the branches doesn't actually delete any content, just a pointer. And all the previous pointings are still in .git/logs/refs/heads/
Also: what riking said.
-
But Git is only for super mega pro computer user expert geniuses!!! Surely those Gods-among-men who use Git know how listboxes work!
It's not CLI therefore not worth learning, because literally everything that can be done on a computer can be done more quickly and efficiently in CLI than GUI
-
<Be careful; someone might take you seriously.
-
@blakeyrat said:
But Git is only for super mega pro computer user expert geniuses!!! Surely those Gods-among-men who use Git know how listboxes work!
It's not CLI therefore not worth learning, because literally everything that can be done on a computer can be done more quickly and efficiently in CLI than GUI
Ah! i knew i was on the proper path with the CLI over GUI approach!
-
<Suck it Ģąşķą
-
<H̵̷̙͈̫͉̟͍͓͇̰̼͑̒̓̒ͮͯͥ͋̆ͧ͑ͤ͐̿͑͢͞ą̢̡̥̖̖̭̪̣̟̿̈́̐͊ͭ́ͅs̷̢̖̬̬̲̰̟̖̲͎̮̳͈̩̳͕͖̲̳̥̉̓̎̊̌͝ ̫͕̬̪̹͚͖̭͎͔̰̲̻͎̙͕͛̓ͮ̿̾͊̋̇̅ͩ͐̃̏̊̈͢͟ý̧̙͎̜̖̲̞̤̏̐͋ͨ͆̆ͫͥͮͩ͗ͣ̒͛͑̒ͥ̈͘͡ơ̸̧̮͈̼̺̫̳̤͇̮͎̦̟̖͖ͤ̔̋ͅͅu̵̵̩͇̻̖̯̠̻̠͍̘̩͍͋͆̎̌̿̔͗͂̄͐ͫ͗̄̏̚̚͝r̴̩̣͖̦̰͇̺̟̤̰ͮ͂ͣ͑ͫ͛͜͜ ̵̘̙̞̫̊ͤ͐̈͂ͦr̷̴̯͍̫̞̺̜̟̞̃ͥ̅̏͒ͯͬ̃ͮ͂ͭͨͪ̆ï̴̙̩̲͚̩̭̪͎̖͇͉͇̥͖̎̍̄̒̓̓̂͠g̸̤͚̣̥̲̱͎̱̜̻̲̫̭̹͖̼͒̐ͤͭ͂̎̅̒͘h̴̢̦̤̥̝̠̖ͩ͋̓͒ͮ̅̏̽ţ̴͚̗̰̼̰̥ͪ̇̂ͬ͢͢ ̶̭͙͎͉͙̳̱̼͔̪̖̗̠̣̯̻̖̏̃ͪ̚͜͡ͅa̷͈̰̺̩̥̩̲̥̭̥̥̬͗̉͌̓͊ͤ͊̓͝ͅl̡̛͔̪̪͕̫̤͓̺͒̈́ͧ̄ͩͬ͞ť̡͕̳̙͎̻̱̙̝͔̲̞̾͆͆͐̈́͂̔̀ ̸̨̧̣̝̞̝̺̱̥͙̹̫̻͛ͭ̊̓̉̃̊͛̓̈́͊̑̓͛ͨ̈́̀̚͢l̡̘̩̻͚͇̜̪̰͉̤̗̗̲͙̍̒ͨ́͒ͥ̓̾̀̚̚͞o̯̻̮̝̜͇̟͕̪̙͊ͩ̈́̽̒ͩ̆̏ͫͧ͗͟ͅc̄̀͐̐̑̓͆ͪ̃̎̾͑͐ͥ̿҉̨͏̷̜͕͕͔̹̖̬̹̪́ͅk̘͇̣̜̩̣̝̣̺̮̖͕̞̆̉̅ͫ̑̿̅̀̑̀͝ͅę̷̼͍͕̻̟̮̫̭̣̱̯̲̝̣͇̺̬̲̆̔́͋̇ͯ̉ͩ͒̏͆̊̈ͧͬ́dͫͧͮ́͘͢͏̼͍̻͎̬͝ ̵̌ͬ̐̅ͥ̾͂ͯ̇ͣ̋͆̌̽͞͡͏̶̹̗̲̲d̛̬͚̻̞͍̭̪͖̺͉̪̓̀̿͂̈̊ͩ̎ͨ̿͊ͣͨ̃̾͗͘͘͟o̴̴̝̟̺̻̱͚̫͍͆̅͐ͥͥ͛ͧ̅̋̾ͯ̎ͣ̕͝w̢̮̫͔̘̬̙͎̝̯̱͖̤̗ͩ͊̾̉̍ͅǹ̴̷̨̘̺̹̟͓̘͚̭͔̪̠̭͉ͯͦ̔̀̇̋ͥ̍̌́ͧ̆͐̔̉̐̈ͦ ̴̻͈̯̘̫̱͓͍̞͈͚͐̾͛͆ͭ̍̄̑ͤͫͯͧ͒͗͆̆̓̐̄͘͢͠ͅo̸̓͊ͩ̐ͣ͋̉͋͜͡͏͎̘ͅr̶̴̨͔̪͇̟̿ͧͦ̈͞ͅ ̧̨̼̤̲̝̺̯̾̏̒ͦͥ̄ͨ͆ͨ͑͜͡͝ͅw̨̲͔̥̣̹̞̥͖̙̗̘̩̪̫ͦ̿ͯ̓ͬ͜͡ͅͅh̢̥̯̖̳͈͙͔̦̬̳̤͉͖͆͗̉͌̏́ͅaͪͩ̇ͤͨ̑̕͏͝͏̙̭̘ͅţ̶̀̈̓͋̅ͥ̌̏͒̓̋ͣ͛̑̈ͦ̂ͯ́͏̜͈̹͔͞?̸̏̅̂̋̾̾ͯ́̚͢͠͞҉̭̥͖̰̞̥̦̼̪̥̳̜̩̺
-
<i'm 16+ and what is this
-
<inb4 blakey raging about us hijacking his topic with offtopic
-
<He'll never find our secret conversation, though. It's completely undetectable.
-
<To him, yes.
-
<even if he does, just blame some git client
-
<it's discourse's fault.
-
<Well there's always Blinking Git Commit Messages: blog.annharter.com/2015/08/12/blinking-commits.html
-
Let's add Blink to our scm.... 😨
-
it's not gits fault. it's xterm. that's the xterm command code that gives you a blinking cursor. or rather makes the text it's on blink and is often used on the cursor character.
correction. s/xterm/vt100/
-
That behavior isn't the problem.
Bullcrap. If you can only operate on one thing at once, you should only allow one to be selected. If you are going to allow multiple selection, keyboard actions should apply to all the selected items. It's a really fucking simple GUI design principle: don't give people the opportunity to even attempt stuff that you don't support so that they are guided away from trying to try to do it in the first place.
If you can't decide whether you are doing single or multiple selection, you need to go away and rethink what you're doing with that interaction because what you'll actually have is a confused mess. And users will notice, even if they're not sure how to express this to you beyond “fucking piece of shit doesn't work!”; it might not be technically accurate, but it's still bang on the money.
If you're iterating a UI design, the first step (beyond fixing things that even you can see are plain wrong) is to watch users using it and learn what things are causing them problems. They may well be not telling you everything that is frustrating them — they might not even notice everything that's frustrating them — but you need to know so that you can figure it out. Using it yourself is also useful, but no substitute; you know too much about how to use the software and so won't do the things that cause most trouble.
-
If you can't decide whether you are doing single or multiple selection
The dialog is unambiguously multi-select.
-
But, compared to earlier versions and other multi-select listboxes with checkboxes, some of the behavior is broken. I have detailed how already.
In VS 2008, those steps would check all of the highlighted items.
-
The dialog is unambiguously multi-select.
Then it should work as @abarker expects. Christ on a crutch, it's not hard to comprehend, is it? I'm not deliberately making it difficult to grasp; if you use multi-select, actions should apply to everything that is currently selected.
What you don't want is an unnatural cross between single-select and multi-select, a frankenstein's monster of GUI interactions. Whoever put the current version of that dialog together fucked up. (It happens.) It might have been by accident or it might have been by design, I don't know which, but it doesn't change the basic fact of fucked-up-ness that has been described.
At this point, I'm nailing the point home hard to try to encourage anyone else doing GUI design to not make the same error. Though if someone at Microsoft reads this and fixes the problem for future versions, more power to your elbow.
-
Funny though; you never see this type of screwup in command-line interfaces.
-
They have different kinds of screwups. The pattern of screwups is pretty characteristic of the type of interface…
