I'm almost out of #emacs packages that are plug-and-play. So today I'm rehashing an old twitter thread about #Magit, THE porcelain for #git.
First, let me talk about my impression of git pre and post magit:
Pre-Magit, I wasn't happy/good at using git.
Post-Magit, I believe all git commands are clunky & unwieldy (especially in comparison to Magit).
The closest that my friends have come to making git better is with copious autocomplete setups (I think it was tmux, fzf, and a few other things). But I still say that magit is probably the lower bound on how nice it can be.
Eg: stage+commit in a wip branch, switch to main, pull from remote, merge wip to main, push to remote is:
S, c c, b b ⏎, F p, b b ⏎, m m ⏎, P p.
Done, in just 16 key strokes. At most there will be a couple of keystrokes extra before each enter if there are multiple branches to select from (but that would be true of any tool).
Not only do the keystrokes feel like the lower bound, the default choices are extremely sane.
Finally, it is not just the minimal keystrokes, it is also the extent of information that magit exposes and the amount of control it provides. Until I started using magit, I didn't know that beyond the usual amend to an earlier commit, you could also expand it (add changes, same msg) and reword it (change msg, no changes). Further, magit also exposes fixup and squash right in the commit submenu (see screenshot). In git, I would have no way of knowing what to do.
Magit is the git porcelain that makes using git feel like doing magic.
My understanding of #Mercurial is that it is very comparable with #Git feature-wise. I only use Git because I discovered it first. It just so happens that it seems to have become the de-facto standard version control system these days.
For those who use Mercurial instead: why? Does it offer something that Git does not, or is it simply personal preference/familiarity?
Was ist denn der beste Git-Hoster der nicht Github heisst? Ich würde gerne mal testweise über den Tellerrand gucken.
Gitlab selber hosten ist raus, hab ich gerade wieder gemacht und für unlustig befunden.
Vertragspartner (und Server) sollten in Europa sein
CI/CD wäre fein, aber kein KO-Kriterium.
Stabile, langweilige, mittelständische Betreiberfirma wäre großartig.
Is it unusual for a #GitHub repository owner to accept PRs, but only by copy-paste-and-rewriting them so that the #git history doesn't show any contribution credit from anyone else? they've made modifications to be sure, but clearly by referencing my code.
I feel like I've been plagiarized, but is there some good reason this is done and I should calm down?
It's just nice have your work acknowledged in the git record, right?
I’ve gone from using the git command-line exclusively to almost exclusively using Sublime Merge.
I basically just keep it open on its own monitor as a real-time dashboard of all my changes. That, and the ease with which you can stage hunks and lines, has improved the quality of my commits and also gives me greater peace of mind.
(Downside: it’s a commercial app and Linux support exists but isn’t first class. e.g., doesn’t automatically respond to light/dark mode changes.)
Concerning my toot from a few days ago concerning more "well-bounded" #dvcs patch workflows, I just discovered #pijul, which seeks to make applying changes commutative (ie the order doesn't matter) based on "theory of patches", "merge correctness", "partial clones" and "first-class conflicts":
"In Pijul, independent changes can be applied in any order without changing the result or the version's identifier. This makes Pijul significantly simpler than workflows using git rebase or hg transplant. Pijul has a branch-like feature called "channels", but these are not as important as in other systems. For example, so-called feature branches are often just changes in Pijul. Keeping your history clean is the default."
So someone made a commit with a future date to #LLVM. As a result, #git now produces a snapshot with dates in the future. Upon running #CMake on files from that snapshot, #Ninja keeps detecting that generated CMake files are older than their sources and rerunning CMake in a loop. Sigh.
I'm hosting my own Git instance for a while now (Gitea) and I'm still not sure if I want to have it as my default/main instance or stick with GitHub as my main.
What would you do?
I'm also very curious what self-hosted instances you guys use.
#git
I have a lot of untracked files that I'm gonna work with later. For now, I just want to see what files I've changed. git status scrolls right past 'em:
git -c color.status=always status | sed -n '/Untracked files/q;p'
Oh ya.. and I like colors even though they're pointless here 😅
Many people seem to agree that part of what makes #git (& #dvcs in general) so difficult to get a really effective handle on is that applying patches is a lot like working with pre-processor macros (ie #define in #C), and that there oughta be a more well-bounded, lexically concise means of code collaboration to establish. But the only work I've seen in this direction is Arun Isaac's tree-diff[1]. #TreeSitter[2] seems like a tool that can greatly ease experimentation in this direction, but what other work has been done on this problem?
I started to review the blog post requests, drafts, and ideas accumulated over time. Most topics revolve around #rex, #perl, #opensource, #gentoo, #cicd, #git, #testing, and #CLI — with some overlap.
Help me decide: which topic shall I focus on first?
A little VS Code / git protip: in your global git configuration, you can setup files that are globally ignored, e.g.,
git config --global --add core.excludesfile "/<full path to your homedir>/.config/git/ignore"
Then you edit "~/.config/git/ignore" and add in the line .vscode/settings.json and your workspace setting overrides will no longer make your repository dirty.