Hacker News Reader

Comment by dgellow | Hacker News Reader

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.

View on HN

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

It’s a professional tool not a hobby, I don’t understand the analogy. Learning to use -p makes you more productive.

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.

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.

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.

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.

It is slower and more error-prone. But some people enjoy that and it's a hobby, which is fine.

Reply on news.ycombinator.com