From Emacs I have two main tools I use to go through a project’s history. Magit’s Log Buffer and vc-annotate-file. With the Log Buffer I can go through a project’s log and open the commit I want to by pressing enter. With vc-annotate-file I can navigate through the previous versions of a file, either by pressing p that takes to me the previous commit and a that takes me to a the previous commit that changed the current line.
To replicate Magit’s Log Buffer the best I could think of is using vim as a ‘smart pager’. The gist of the idea being to pipe the output of git log to vim, record a macro that copies the current word and calls git show (qqyiw:!git show <C-”>q) and use the current vim buffer to navigate through the commit log and type replay the macro (@ q / @@`) when I want to open the details of the commit. Which I think is pretty neat. I’ve made a quick ascii-cast showing the idea in action.
https://asciinema.org/a/GFDYWayzBFpkTAkVscC1QGQu3
For vc-annotate-file I am at a loss of how people would navigate in a comfortable way a file’s history, I guess could get half of the way there using the aforementioned trick combined with the -S/G/--grep/-L options of git log
I’m curious, what are the workflows to go through a project’s history from those who use git from the CLI?
P.D. Yes I should have used 0 at the start of the macro to avoid jumping the the commit sha after searching for a commit message with /. Sorry I don’t use vim.
Other than regular old git commands, I like Tig.
I nearly always just use
git log --all --decorate --oneline --graphin the terminal rather than anything in vim, which I have aliased togit adog. Or I just use plain oldgit log. If I really wanted to navigate the history of a file I guess I would use:Glogfrom Tim Pope’s vim-fugitive plugin, the documentation for which I will quote:Load all previous revisions of the current file into the quickfix list. Additional git-log arguments can be given (for example, --reverse). If "--" appears as an argument, no file specific filtering is done, and previous commits rather than previous file revisions are loaded.I’ve never actually needed to do this, but I did :help fugitive when I saw the thread. It seems very useful. I have
<F3>and<F4>globally bound to:cprev<CR>and:cnext<CR>so I can flick through revisions with them. It’s all very fast as well.I wouldn’t call it a need either. But since I found out about
vc-annotate-file. I’ve found it pretty useful and a quicker way to get around the project’s history. Especially in FLOSS context’s when the author is not readily available for you to ask about why the code was written this or that way. Especially when the changes are not recent (for those the log buffer works best) as navigating a file’s history only takes a couple of keystrokes.I have the theory that part of the reason of the decline of commit messages is because people don’t read them, so why waste time in something no-one, not even oneself will read? And that the reason people don’t read them is because it is cumbersome to do so. Especially from the CLI, which is what I see most people using. So I was curious to. There a some graphical tools that are pretty good, like Tower or Gitk mentioned in another thread but I don’t see them used very often. Also Editor specific integrations like
:fugitive, which solve the problem as well.If I didn’t use Emacs I would have switched to Fossil a long time ago.
Gitk. Launches very fast and doesn’t try to be anything more than just a log viewer.
gina (“fast”) or fugitive (mature and popular) and gv.
I just use the webUI for gitlab
Plain old
git logandgit reflog, really. Sometimes I use the webui on GitHub or GitLab, but they are quite clunky.I use Mercurial via hg-git.
That gives me templating, revsets, hg absorb, Evolve, and a bunch of other goodies that make it really easy to read history and rewrite draft commits (and also rewrite published history, with a little bit of
--force, but I pretty much never do that).I use the command line.
“glo” means “git log –oneline”, “gloa” for “–decorate –all –graph”. “git log -S” can be very useful sometimes. “git {tag/branch} –contains” as well.
I otherwise use git blame and start from there. I made an alias for blaming specific lines with references of the form “path/to/file.ext:l”, which is recurring in most debugging tools (compiler, stack trace, diff, etc). So my alias will consume this and feed it to some “git blame -L${line},+1 $ref – $file”. This way I can very quickly see the ref for a specific line, and then see the previous ref for the same line, etc.
I don’t generally need to see a whole file in a specific version, I find the commits sufficient. If I really need to load a specific version, I will checkout the ref.
I have an alias called
git mapthat maps toIt usually does what I need to do, but I’d be happy to hear about better GUI tools.
On this topic does anybody have a good way to address the question “what other branches will have a merge conflict with this one after this merges into master”?
I have these aliases in my
.bash_profile:I use
lp <filename>when I want to see a history of some file. If I know a particular string that interests me, I add the-Sflag:lp <filename> -S <string>. I uselofor “general” history view, when I need a “bird’s eye view” of a branch.If another version control system eventually supercedes git, I hope that a UI as powerful/easy will be considered a minimum requirement (I’m looking at you Fossil/Hg/Pijul).
git loggitk(when I remember it exists)I almost always use the history browser, inline annotations and diff tools available in the Intellij IDEs that I use.
@PuercoPop you got me to try to play with vc-annotate-file, but when I try to hit something simple like
C-x v =it says “File ___ is not under version control” Strange that it doesn’t prompt me to configure it. Any idea where it may be caching this stuff? I have no.emacs(normally a *Vim user).With no configuration, you should go the file in question, then enter
C-x v gFrom there you can navigate the history with ease using the single letter actions listed later in the manual
Thanks. My stock emacs on Mac was staler than I thought. Worked out of the box after an upgrade. (Folks on #lobsters helped me figure it out.)
As a long-time Emacs and Magit user, I don’t use Magit to navigate the commit history, I just use
git logon the command line (orgit log --statorgit log -porgit flog, where'flog' is aliased to 'log --all --decorate=short --pretty=oneline --graph'). For a single file, I tend to justgit log [-p] -- src/thefile.c. I’ve tried the magit log, but I’m just more used to the shell for that.I love magit, but trying to use
magit-log-*on a repository with more than half a million commits reeeeeeally drags on, so it’s magit for reasonable repos and plaingit log --show-notes=* --abbrev-commit --pretty=format:'%Cred%h %Cgreen(%aD)%Creset -%C(bold red)%d%Creset %s %C(bold blue)<%an>%Creset'(aliased) for monorepos.Have you tried tig? https://github.com/jonas/tig