A surprising upside to vc-dir marks over magit

vc.el is Emacs’s built-in interface for version control CLI tools. With respect to Git, magit has for several years now been the most favored (with respect to popularity) Git¹ interface. At least in the r/emacs subreddit, magit is frequently considered a killer-feature—an irreplaceable feature unique to Emacs.

For the most part I am inclined to agree. However, in the last few months, I’ve been regularly experimenting using vc. This is in part motivated by recent improvements to vc’s implementation of Git, and another part motivated by a curiosity to see whether I’d end up enjoying some parts of the vc-way of doing things over the magit-way of doing things.²

On such insight has been the surprising benefits of calling vc-dir instead of magit-status.

The nicety of vc-dir marks

In magit-status, I would typically stage various files and hunks and commit them when ready. vc does not use Git’s “staging” concept (because not all version control systems use such a concept). So instead, to achieve something analogous, a user might call vc-dir (or, much more commonly for me, project-vc-dir), mark edited files (or entire directories!) using vc-dir-mark (m), and check out (commit) those changes via vc-next-action (v) or see a diff of those changes with vc-diff (=) and commit the changes in that diff-mode buffer (v).³

A problem for the magit interface, however, is visual clarity when it comes to focusing on changes in a certain subset of files. For example, sometimes I am working with changes in files within a single directory alongside many other uncommitted changes elsewhere in the repository. To make a commit with magit, I would need to navigate past or fold changed hunks/files I want to ignore. With many unstaged changes this means many files to ignore. This leads to a significant reduction in visual clarity since I end up having to ignore more files than I’m currently working on.

There is a subtle solution in vc.el. The secret lies in the fact that marks, which can be used to selectively create diff buffers and commit changes from those buffers, are preserved in vc-dir buffers after changes are committed. A mark is only removed once the corresponding line is removed via something like vc-dir-hide-up-to-date (x) or vc-dir-kill-line (C-k). Marks are magical because they let me focus on the files relevant to my current work: I can mark the files and directories I am focusing on then call vc-next-action in the vc-dir buffer to commit changes only in those files and directories (or, if I want to be selective about the hunks I commit: first call vc-diff to see the diff of just the marked files, kill/remove the hunks I don’t want to commit, then vc-next-action).Then I can write more changes and make more commits in the same way. (Furthermore, while this vc workflow might seem like it would necessarily involve many more keystrokes, I found this not to be the case under certain scenarios.)

Effectively, in short, while magit can sometimes become visually cluttered, vc-dir marks let users focus on their current work by easily excluding from view files and directories one is not concerned with currently.

A caveat

Historically, I’ve found this especially fruitful when working on my literate Emacs config⁴ (wherein any “single change” involves changes to the .org file as well as the resulting tangled file(s)) and Emacs packages. Still, I think I prefer magit in cases where the staging functionality of Git is crucial. For instance, I have a repository that houses all my org notes and org-agenda files. There are frequently many changes for this repository, so the convenience of staging/unstaging has been crucial for me. In cases like these, I haven’t found an equivalent for vc.el yet.