4 ms·
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 lo
by 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 agoYou 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 agoIt 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.
- iraqmtpizza 3y agoIt is slower and more error-prone. But some people enjoy that and it's a hobby, which is fine.