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)
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.
GitHub Desktop is quite limited and I hope it stays that way, I still use the cli for operations other than commit and checkout.
Sorry, what? A command line IS a UI. And it happens to be great for displaying text, like what is displayed with git diff...
Side note: there are also GUIs for the terminal, they’re fine.
I can then run git status -v to show what's currently staged, write the commit message and filter it through the git commit command.
> there’s no way you can review (and pick or discard) your 100-lines 5-files changes effectively on the command line.
It's easy enough to find the approriate hunk and edit the diff to stage what's needed. I may go through the process a few times to create a single commit depending on how many hunks I have to deal with and how many times I need to split them though.
In fact, my normal workflow is to make the necessary changes for a particular feature I'm working on, take the diff against the base branch and then stage parts of that diff to create a series of sensible commits for the branch.
That has changed over the years. I use a few custom created aliases + specific Workflows how I go about making changes to a project.
I’m not interested in any of the fancy git UIs (sourcetree, tower, fork, kraken) because each tries to simplify git and or would break my workflow. For instance I don’t use Explorer, Finder etc to traverse files. I open a new terminal session and cd through my file system. I have a strict setup which I replicate on the different machines/VMs I use so I know it from memory. I don’t need to switch to a UI tool that knows where all my checkouts are and klick a terminal button to start a session there. I work from the terminal and open Idea, VSCode or vim from the project. The latter is the reason I could not adopt eMacs as it didn’t really work well for me with this kind of workflow.
And last. I stopped doing multiple fancy changes all at once in a project that would warrant the use of specialized tools or UIs. If I see that a change gets out of hand I start to formulate base batches on the go. I can create a series of commits and split them up/rebase afterwards.
But I don’t Stopp anyone from doing it differently. We are all wired differently and use the given tools how we feel best.
Ah also working with a lot of remote headless machines it is nice if you know you way around the cli in general. Or my favorite issue I had the last couple of weeks switching from Nvidia to AMD (X-Server did not start) issues ;) No ui to help to fix this.
But after I picked up emacs again and started using magit even that became a breeze.
Also, for reviewing changes, I use the no context option `git diff -U0`and more recently use git-delta for better color highlighting and the side-by-side diff view.
I also think in addition to just having learned and practiced over a decade, the way I’ve used Git has evolved too. I keep PRs small and cohesive, always squash all their commits, and because of that I don’t have to care so much about untangling cohesive changes at commit time, although I also don’t let them pile up. I usually do a lot of `git commit --amend` and `git commit --fixup` (more and more rarely actually followed by a `git rebase --autosquash` since the PR takes care of the squash now… I don’t even have to worry about order-based conflicts anymore).
Does anyone have any tips for integrating it into an emacs workflow? I'm currently doing `git commit` from shell which launches emacs-nox with magit.
Perhaps the author had different motivation to start it, which is why I posted this question — the demo explain what the program does but provide little context other than extracting actual patches, and then again, it begs the question of 'why'.
The demo recording is good and I think it would be even better to state the motivation/use case explicitly in the README.
Sadly P4 fumbles at the 10 because you can't split changes by hunk, file only.
I hope something like this (or maybe just multiple named stages?) makes it into git.
Largest complaints currently are the infesibility of the feature-branch workflow and the terribad pre-commit code review story.
Probably doable and shiftable to a git-splitpatch too.
The key value of `split-patch` is that you can create as many patches (commits) as you want by doing a single pass over the (potentially large) patchset.
If you're willing to do multiple passes over the patchset, you could `git commit` right away.
Anyway, cool, I didn't know you could name stashes!
(You can even `git cherry-pick stash@{0}^` for the commit the stash was made at. It really is just a commit made at that point, with that parent, only without updating HEAD, or the checked-out branch.)
In Git, you can stage files (git add). You have only one “staging area”. In Perforce, you can also stage files (of sorts). You can create as many “staging areas” (changelists) as you want. Changelists are publicly visible, if so desired, before they are even “committed” (submitted, in P4 jargon).
Changelists work on entire files, unlike what TFA proposes.
https://www.syntevo.com/smartgit/
Anyone have alternatives for Linux?
Nowadays I just do a few rounds of git add -p; commit, or trusty ole git commit -av
What version of git are you using? You probably want to check with `git --version`.
The latest version is 2.35.1.
Both git gui and gitk are still in the git repo AFAICT:
https://github.com/git/git/tree/master/git-gui https://github.com/git/git/tree/master/gitk-git
If CI isn't running tests for every PR, `git add -p` can create pretty patches that fail when attempting to `git bisect` later.
> 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`.
