I find it crazy how many people like working with git from the command line and just use -a any chance they get.<p>I never commit from CLI and have been using GitHub Desktop for years (it works on any repo/remote). Selecting individual files, patches, or even lines is a breeze. I usually make a bunch of changes, then pick, commit, branch, repeat. Every branch is based off `main` and can be pushed independently. Any leftover will just be dropped (any logging/testing lines that I never picked, for example)<p>Using a UI makes it easy to review your changes before you commit them, there’s no way you can review (and pick or discard) your 100-lines 5-files changes effectively on the command line.<p>GitHub Desktop is quite limited and I hope it stays that way, I still use the cli for operations other than commit and checkout.
There's a set of utilities[1] in a package called patchutils that contains several commands to manipulate patches. Their version of splitdiff[2] will create a set of patch files from a single patch where each patch would only apply to a single file. It doesn't appear to have the capability of splitting out individual hunks like your version, but could be updated to do so.<p>[1] <a href="https://directory.fsf.org/wiki/Patchutils" rel="nofollow">https://directory.fsf.org/wiki/Patchutils</a><p>[2] <a href="https://www.unix.com/man-page/suse/1/splitdiff/" rel="nofollow">https://www.unix.com/man-page/suse/1/splitdiff/</a>
This is the one P4 workflow feature I wish git had from the beginning. In Perforce, changes can be grouped into uncommitted "change lists." Its really helpful if you're working on multiple things especially when they're unrelated features or projects. Works very well for artists and such.<p>Sadly P4 fumbles at the 10 because you can't split changes by hunk, file only.<p>I hope something like this (or maybe just multiple named stages?) makes it into git.
Is the main use case being splitting large uncommitted change set into logical units in _one pass_ rather than few iterations of `git add -p && git commit`?
There are probably a couple good ways to avoid trying to split `git add -p` with e.g. jujutsu `jj`?
<a href="https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md" rel="nofollow">https://github.com/martinvonz/jj/blob/main/docs/git-comparis...</a><p>If CI isn't running tests for every PR, `git add -p` can create pretty patches that fail when attempting to `git bisect` later.<p>> <i>Comprehensive support for rewriting history: Besides the usual rebase command, there's `jj describe` for editing the description (commit message) of an arbitrary commit. There's also `jj edit`, which lets you edit the changes in a commit without checking it out. To split a commit into two, use `jj split`. You can even move part of the changes in a commit to any other commit using `jj move`.</i>
This is great, I've been using Sublime Merge similarly in my workflow. I stage individual files while drafting the commit message and make sure to split lines across commits for logical rollbacks. I personally find it a lot faster than using the CLI, at least in this case.
I was looking a few years ago for a GUI for git, on linux. I eventually settled on SmartGit, been using it since..<p><a href="https://www.syntevo.com/smartgit/" rel="nofollow">https://www.syntevo.com/smartgit/</a><p>Anyone have alternatives for Linux?
Oh this is interesting. Sometimes I make unrelated changes and then I want to tease the things apart at commit time. And when I do I find that I don’t just want to stage or skip staging. Worth a shot but I’d prefer if I could put it into secondary staging and post-commit the first of those becomes staged.<p>Probably doable and shiftable to a git-splitpatch too.
See also Mercurial Queues (<a href="https://www.mercurial-scm.org/wiki/MqExtension" rel="nofollow">https://www.mercurial-scm.org/wiki/MqExtension</a>)