4 ms·

git blame shows only who made the last change. Maybe that person only changed the name of a variable, applied a codestyle change, moved a function declaration t

by ozay 3y ago

git blame shows only who made the last change. Maybe that person only changed the name of a variable, applied a codestyle change, moved a function declaration to another file or many other things that the change was almost irrelevant to the code behavior. There are a few options that help you out with this: -M Detect moved or copied lines within a file -C In addition to -M, detect lines moved or copied from other files that were modified in the same commit. --ignore-rev <rev> Ignore changes made by the revision when assigning blame, as if the change never happened --ignore-revs-file <file> Ignore revisions listed in file https://git-scm.com/docs/git-blame https://git-scm.com/docs/git-blame

PhilipRoman 3y ago
I recommend just skipping blame and going to git log -L to see the full evolution of a range of lines, I set up a little keybind in vim which does this for the current visual selection and it works much better than blame.
- a_e_k 3y ago
  And for those using Magit in Emacs, you can do this by selecting a region of lines and hitting `C-c M-g l`. https://magit.vc/manual/magit/Commands-for-Buffers-Visiting-Files.html#index-C_002dc-M_002dg-l https://magit.vc/manual/magit/Commands-for-Buffers-Visiting-...
  - agumonkey 3y ago
    There's also git time machine to quickly rollback a buffer in place
  - karthink 3y ago
    This feature is built into Emacs, no Magit needed. It's the vc-region-history command, bound to `C-x v h` by default. It works across all version control systems Emacs supports, not just git.
- jmholla 3y ago
  Nice. Can you share your vim configuration for that?
  - PhilipRoman 3y ago
    My config is kind of cluttered so this is a simplified version without dependencies. Glogr is for range history, GLogf for file history and <leader>gc for showing a commit based on hash: nnoremap <leader>gc :Gshow <C-R><C-W><cr> command! -nargs=1 Gshow enew | set ft=diff buftype=nofile | 0r!git log -p -n 1 "<args>" command! -nargs=0 Glogf tabnew | set ft=diff buftype=nofile | 0r!git -C "#:h" log -p --follow "#:t" command! -nargs=0 -range Glogr tabnew | set ft=diff buftype=nofile | 0r!git -C "#:h" log -L "<line1>,<line2>:#:t"
eru 3y ago
I wish they would make long option names for everything, including -C and -M. (Perhaps I should contribute that..) I use short options interactively on the command line, but in scripts and when communicating with other people, I prefer longer options because they are self-documenting and can catch most typos. (For a long option, typos are more likely to result in an invalid option, and thus an error message. For one-letter options, a typo could result in anything..)
- penguin_booze 3y ago
  FWIW, -C has precedents: `make` and `tar` have the same option with the same meaning.
  - eru 3y ago
    Yes, sticking to precedent is a good idea in general, too. But that's independent of long options.
parentheses 3y ago
These are the things that can be a chore to find in man pages. There needs to be a way to "sort" man page elements to show most commonly used switches first.

by ozay 3y ago

PhilipRoman 3y ago

I recommend just skipping blame and going to git log -L to see the full evolution of a range of lines, I set up a little keybind in vim which does this for the current visual selection and it works much better than blame.

a_e_k 3y ago
And for those using Magit in Emacs, you can do this by selecting a region of lines and hitting `C-c M-g l`. https://magit.vc/manual/magit/Commands-for-Buffers-Visiting-Files.html#index-C_002dc-M_002dg-l https://magit.vc/manual/magit/Commands-for-Buffers-Visiting-...
- agumonkey 3y ago
  There's also git time machine to quickly rollback a buffer in place
- karthink 3y ago
  This feature is built into Emacs, no Magit needed. It's the vc-region-history command, bound to `C-x v h` by default. It works across all version control systems Emacs supports, not just git.
jmholla 3y ago
Nice. Can you share your vim configuration for that?
- PhilipRoman 3y ago
  My config is kind of cluttered so this is a simplified version without dependencies. Glogr is for range history, GLogf for file history and <leader>gc for showing a commit based on hash: nnoremap <leader>gc :Gshow <C-R><C-W><cr> command! -nargs=1 Gshow enew | set ft=diff buftype=nofile | 0r!git log -p -n 1 "<args>" command! -nargs=0 Glogf tabnew | set ft=diff buftype=nofile | 0r!git -C "#:h" log -p --follow "#:t" command! -nargs=0 -range Glogr tabnew | set ft=diff buftype=nofile | 0r!git -C "#:h" log -L "<line1>,<line2>:#:t"

eru 3y ago

I wish they would make long option names for everything, including -C and -M. (Perhaps I should contribute that..) I use short options interactively on the command line, but in scripts and when communicating with other people, I prefer longer options because they are self-documenting and can catch most typos. (For a long option, typos are more likely to result in an invalid option, and thus an error message. For one-letter options, a typo could result in anything..)

penguin_booze 3y ago
FWIW, -C has precedents: `make` and `tar` have the same option with the same meaning.
- eru 3y ago
  Yes, sticking to precedent is a good idea in general, too. But that's independent of long options.

parentheses 3y ago

These are the things that can be a chore to find in man pages. There needs to be a way to "sort" man page elements to show most commonly used switches first.