So I was confused because the options to choose from for C-x v ~ only showed older revisions of the file on this particular branch, but you can in fact specify a branch and have that file shown.
Ie. if you want to visit the current file on master:
C-x v ~
Then just specify
As suggested by @KyleMeyer, the Magit command for this would be
Well, vc does that by default. From its documentation (emphasis mine):
When you visit a file that is under version control, Emacs indicates
this on the mode line. For example, ‘Bzr-1223’ says that Bazaar is used
for that file, and the current revision ID is 1223.
The character between the back-end name and the revision ID indicates
This is possible in Emacs 26.1. You need to set the configuration variable vc-git-print-log-follow to t. The functionality was implemented in the following commit:
That change is a workaround for Emacs bug #8756: vc-git.el doesn't use --follow argument in vc-git-print-log ...
How can I customize the appearance of vc-mode? Ideally, I’d hide the name of the backend, and show just the name of the current branch.
That's pretty much what
You can give it a try, or you can just copy the advice that it uses:
(defadvice vc-mode-line (after strip-backend () activate)
(when (stringp vc-mode)
(let ((noback (...
Magit can do this by limiting the revert action to the region.
With the built-in diff-mode you can get the same kind of effect by splitting the hunk into portions using diff-split-hunk
which is bound to C-c C-s by default.
I was not happy with the default behavior either. I could never keep the vc info characters straight— ":" for edited, "@" for added, etc. You can feel free to use my method.
I defined several custom faces to display the statuses in various colors. Then I wrote a function to translate the default vc info into a string to insert into the mode line. Then I ...
I don't use anything else than GIT as well so i have this advice specific to vc-git
(advice-add #'vc-git-mode-line-string :filter-return #'my-replace-git-status)
(defun my-replace-git-status (tstr)
(let* ((tstr (replace-regexp-in-string "Git" "" tstr))
(first-char (substring tstr 0 1))
(rest-chars (substring tstr 1)))
This information is being updated by the VC package that is part of Emacs.
Many users have noticed that this information isn't always being updated when it should and asked about that problem in many different places, or reported as a bug in some unrelated package/project such as Magit or Spacemacs.
Because this has been reported as a Magit bug or feature ...
I figured it out. Following method 2 outlined in this answer, I just redefined the function vc-steal-lock by commenting out the chunk of code that has to do with emailing the person from whom you stole the lock.
'(defun vc-steal-lock (file rev owner)
"Steal the lock on FILE."
Use vc-refresh-state like this to get rid of the edited vc-state:
(defun vc-state-refresh-post-command-hook ()
"Check if command in `this-command' was executed, then run `vc-refresh-state'"
(when (memq this-command '(other-window kill-buffer ido-kill-buffer ido-switch-buffer))
(add-hook 'after-save-hook 'vc-refresh-state)
The VC packages uses caching, and in many places assumes that the user interacts with VCS systems (e.g. Git) through it.
To register a new file in a Git repository, press C-x v v, you don't need to use Eshell for that.
If you've changed a buffer's status using something else than VC commands, though, you can visit the file again to refresh the status ...
Emacs caches version control information for each buffer.
If you visit a file first, and then git add it in a terminal, Emacs doesn't know this. You can M-x revert-buffer to force it to refresh the cache, or kill the buffer and visit the file again.
In the future, you can register such files from within Emacs, using vc-next-action, by default bound to C-x ...
Indeed, all those diff options work line-by-line, and insertion/removal of newlines creates completely different lines so they don't see those changes as "just whitespace".
You need to use a word-based diff or something like that. Emacs comes with one such functionality which is the "refined" highlighting. It's available both in smerge-mode and in diff-...
As far as I can tell, you need to modify the function git-vc-print-log. It only has some limited configurability, and that's not enough for you. You can change the variable vc-git-root-log-format to change what vc-print-log displays for a directory, but that only gives you a value that's passed to git log --pretty=tformat=, and there's no option to include ...
C-hv vc-post-command-functions will probably get you the majority of them, but not necessarily all of them.
For instance, I note that vc-git.el uses its own internal vc-git--call for a handful of things (where presumably there was some problem with going via the standard channel).
vc-diff-internal doesn't show single changeset but always diff between two revisions.
vc-diff-build-argument-list-internal function used by commands vc-version-diff and vc-root-version-diff will ask for revisions to compare.
log-view-diff-common used to view diff from log view compute previous revision by calling backend for previous revision so we can do ...
Use C-c c-e in the vc-diff buffer to apply the diff to a file. Enter the target filename and press RET. This will launch ediff and attempt to apply the patch.
For me, the patch applied successfully without any hitches, so I just needed to press n a few times in the ediff frame to review the result, and then q to quit the ediff session.
Then return to the ...
I came up with something like this.
(defun vc-status ()
(let ((backend (vc-responsible-backend default-directory)))
(cond ((equal 'Git backend) (magit-status))
((equal 'Hg backend) (ahg-status)))))
Documenting my own crude solution for now, in case it helps anyone. I'll happily accept another answer with a better solution.
My solution took the form of two parts:
Wrapper shell script around BusyBox's diff, converting its unified output into traditional/"normal" output. (It's now in one of the directories in my PATH as bnudiff. I put it on GitHub it ...
After update of MacOS (10.14.6) I had the same "This file is not under version control" - turns out that I needed to accept xcode license to run git commands.
In terminal just do a sudo xcodebuild -license- that fixed my problem.
Check the manual about version control info in the mode line, specifically the part about auto-revert-check-vc-info.
If you set auto-revert-check-vc-info to t, Auto Revert mode updates the version control status information every auto-revert-interval seconds, even if the work file itself is unchanged. The resulting CPU usage depends on the version control ...