3 ms·

(1/1) Stage this hunk [y,n,q,a,d,s,e,?]? (2/5) Stage this hunk [y,n,q,a,d,K,j,J,g,/,e,?]? Wow, so intuitive! LOL. You really showed him. This UX is laughably

(1/1) Stage this hunk [y,n,q,a,d,s,e,?]? (2/5) Stage this hunk [y,n,q,a,d,K,j,J,g,/,e,?]? Wow, so intuitive! LOL. You really showed him. This UX is laughably bad. It presents you every hunk, one at a time, without context, and if you want to include some lines and not others, you can't unless all the sub-hunks are exactly one line or you let it launch a text editor and you dick around in the raw diff which is its own domain-specific language. Why don't people play starcraft like this? (1/1) Move this zergling [u,d,l,r,b,a,J,g,/,e?]? The fact that this needs a write-up and discussion is all you need to know. Where is the big how-to for committing partial files in GitHub Desktop? Oh, yeah, nobody needs one because it's obvious and right in front of your face. If you have no limbs and can't use a mouse to click on things then this UI is great though.

dgellow 3y ago
It’s really easy to learn: one of the option is ‘?’, try it out, it will give you more explanation. The ‘s’ to split changes is one of my favorite feature. It takes a few minutes to get used to it, then becomes automatic: add the whole file ‘a’, skip file ‘d’, skip chunk ‘n’, stage chunk ‘y’, split ‘s’, stop here ‘q’, rollback ctrl-c. The “chunk per chunk” approach is actually really nice, you’re focusing on what exactly you want to get your commit to be about. You learn it once, that will never change, you’re set for decades.
- iraqmtpizza 3y ago
  It's really easy to learn how to use a slot machine too. Or dwarf fortress. It's not productive -- it's a hobby at best. EDIT: You have extremely low standards for what constitutes a professional tool these days. You also didn't address my point. split is brain damaged and doesn't work: + assertEquals(byte[].class, p.get0().getClass()); + assertEquals(String.class, p.get1().getClass()); You try to split this hunk and it won't do it. This task is beyond trivial in any non-retarded GUI. -p makes you more productive because you don't know how to use an electron app or Java app
  - dgellow 3y ago
    It’s a professional tool not a hobby, I don’t understand the analogy. Learning to use -p makes you more productive.
    - IshKebab 3y ago
      It makes you more productive than not splitting commits at all. It doesn't make you more productive than doing it in a GUI. It's like you're saying "guys you should use this new hand drill I've discovered! It's so much more productive than digging holes with an awl!" while ignoring the fact that electric drills exist.
  - Chris_Newton 3y ago
    Is there something unusual about your example that means (e)dit doesn’t work if you want to treat those lines as separate hunks? Usually if you have multiple logical changes that are adjacent and get recognised as a single change by default, you can just open your editor and keep the lines you want to stage, much the same as you’d do by marking the lines you want to stage in most of the interactive GUIs built on top of Git.
    - iraqmtpizza 3y ago
      You shouldn't have to edit a raw diff which is its own language just to split two adjacent lines. I'm not saying it should be fixed, I'm saying people should stop using the command line to do this entirely. (I find it quite funny that they ever did.) Oh, I forgot that it probably couldn't be fixed even if they wanted to because if split suddenly started working it would break someone's spacebar heating script.
      - Chris_Newton 3y ago
        It seems a stretch to call having a + character at the start of an added line “its own language”. Staging one line of the two in your example probably takes less than five seconds using this method; in the editor, you just delete the line you don’t want. If you personally prefer a GUI then that’s obviously your choice. Some people do and I doubt you’ll find many people claiming Git has the world’s best UI. It does work everywhere, though, and I doubt it’s any slower than using a GUI for a task like your example. Either way, you can have lines staged or not pretty much as fast as you can read them and decide whether they should be.

dgellow 3y ago

It’s really easy to learn: one of the option is ‘?’, try it out, it will give you more explanation. The ‘s’ to split changes is one of my favorite feature. It takes a few minutes to get used to it, then becomes automatic: add the whole file ‘a’, skip file ‘d’, skip chunk ‘n’, stage chunk ‘y’, split ‘s’, stop here ‘q’, rollback ctrl-c. The “chunk per chunk” approach is actually really nice, you’re focusing on what exactly you want to get your commit to be about. You learn it once, that will never change, you’re set for decades.

iraqmtpizza 3y ago
It's really easy to learn how to use a slot machine too. Or dwarf fortress. It's not productive -- it's a hobby at best. EDIT: You have extremely low standards for what constitutes a professional tool these days. You also didn't address my point. split is brain damaged and doesn't work: + assertEquals(byte[].class, p.get0().getClass()); + assertEquals(String.class, p.get1().getClass()); You try to split this hunk and it won't do it. This task is beyond trivial in any non-retarded GUI. -p makes you more productive because you don't know how to use an electron app or Java app
- dgellow 3y ago
  It’s a professional tool not a hobby, I don’t understand the analogy. Learning to use -p makes you more productive.
  - IshKebab 3y ago
    It makes you more productive than not splitting commits at all. It doesn't make you more productive than doing it in a GUI. It's like you're saying "guys you should use this new hand drill I've discovered! It's so much more productive than digging holes with an awl!" while ignoring the fact that electric drills exist.
- Chris_Newton 3y ago
  Is there something unusual about your example that means (e)dit doesn’t work if you want to treat those lines as separate hunks? Usually if you have multiple logical changes that are adjacent and get recognised as a single change by default, you can just open your editor and keep the lines you want to stage, much the same as you’d do by marking the lines you want to stage in most of the interactive GUIs built on top of Git.
  - iraqmtpizza 3y ago
    You shouldn't have to edit a raw diff which is its own language just to split two adjacent lines. I'm not saying it should be fixed, I'm saying people should stop using the command line to do this entirely. (I find it quite funny that they ever did.) Oh, I forgot that it probably couldn't be fixed even if they wanted to because if split suddenly started working it would break someone's spacebar heating script.
    - Chris_Newton 3y ago
      It seems a stretch to call having a + character at the start of an added line “its own language”. Staging one line of the two in your example probably takes less than five seconds using this method; in the editor, you just delete the line you don’t want. If you personally prefer a GUI then that’s obviously your choice. Some people do and I doubt you’ll find many people claiming Git has the world’s best UI. It does work everywhere, though, and I doubt it’s any slower than using a GUI for a task like your example. Either way, you can have lines staged or not pretty much as fast as you can read them and decide whether they should be.