7 ms·

For those who resonate with "why might this be useful", here are "plain git" alternatives to this tool: > searching for a function I deleted git log -G so

by mbakke 3y ago

For those who resonate with "why might this be useful", here are "plain git" alternatives to this tool: > searching for a function I deleted git log -G someFunc > quickly looking at a file on another branch to copy a line from it I use `git worktree` to "mount" long-running branches much to the same effect as Julias tool. To quickly look at a file from a non-mounted branch/commit, I use: git show $REF:$FILENAME > searching every branch for a function git log --all -G someFunc Note that -G can be replaced with -F for a speedup if the pattern you are searching for is a fixed string.

levidos 3y ago
Extremely handy, saving these. Thank you.
globular-toast 3y ago
Magit has a really easy to use way to "step" through previous versions of files. It's usually bound to something like "C-f p". You get a read only buffer of the previous version open in the best text editor (emacs). You can then press n and p to step through next and previous versions of that file. Can be pretty useful! It's kind of funny, I think, how most git users don't seem to know how to access any version other than the current one. So many people think of it simply as the annoying tool you have to use to make code changes but don't really know what version control is.
- divbzero 3y ago
  That’s a pretty cool feature of Magit. I was inspired to look for something similar for the next best text editor (vim) and came across this: https://salferrarello.com/using-vim-view-git-commits/ https://salferrarello.com/using-vim-view-git-commits/ git log | vim -R - Placing your cursor over a commit hash and entering K displays git show for that commit.
  - cnity 3y ago
    If you're not using neovim you're really missing out right now IMO. It's a renaissance for a hackable text editor because it uses a sensible modern programming language (Lua) rather than vimscript (yikes) or elisp (eh).
    - globular-toast 3y ago
      You may be missing the point of Elisp. Elisp isn't an "extension language". It's the language Emacs is built with. When you run Emacs you're actually running a Lisp interpreter with a load of text editing features pre-loaded. When you eval some Lisp you're modifying the runtime, essentially live patching your editor in real time. So really any comparisons with Elisp are irrelevant unless you can do what it can do. Common Lisp and Scheme (Guile) are real contenders but the challenge is not giving up the enormous amount of useful code that is already written in Elisp.
      - galangalalgol 3y ago
        Does the elisp interpreter that runs emacs have jit?
        fourthark 3y ago
        Only with v28, a year or two ago.
        klibertp 3y ago
        That's not a JIT. It uses `libgccjit` (IIRC the name), but the native code is produced ahead-of-time. JITs compile using info available on runtime, and native-comp doesn't do that. LuaJIT, by contrast, is a "real" JIT. Still, native-comp does speed things up considerably.
      - cnity 3y ago
        I'm a big lisp fan. I know about all of this, I used emacs for maybe a decade, and I still don't like elisp. I love the hackability of Emacs, but it's OK to dislike the language itself. Disliking semantic choices of the language doesn't mean I'm missing the point either! And on "it's not just an extensibility language": in my experience this doesn't matter. I get that "well the editor itself is half written in elisp" and so vaguely that is superior, but it is only so in an academic sense. Expose the primitives for the editor in some API in _any_ langauge and you can basically achieve the same thing anyway, so pick a language that doesn't make me want to poke my eyeballs out with a hot skewer. Sorry, rant over.
  - sourcegrift 3y ago
    I've been told by my elders that when a vim user encounters an emacs supremacist, they must fight back. You can't just call it "the next best text editor". Jokes aside, As a vim user of 6 years, I did learn just enough emacs for magit (TM) and have also been making quick bucks on the side teaching it to my friends , so I guess I can't help with the "fight back" part :-)
  - fiddlerwoaroof 3y ago
    Or I could use magit inside the best implementation of the vi standard.
- masklinn 3y ago
  My bread and butter is jumping via blame, though I don’t really like emacs’ blame view so I generally use intellij or git gui. e.g. see something odd / interesting, activate blame view, and “show diff” / “annotate previous revision” to see how the hunk evolved. Often this provides fast-tracking through the file’s history as the hunk goes through inconsequential changes (e.g. reformatting, minor updates) without changing the gist of what sparked your interest.
  - fiddlerwoaroof 3y ago
    vc-annotate in emacs is my favorite blame view I’ve seen, if you haven’t tried it.
- cnity 3y ago
  Similarly with fugitive in vim, which is fantastic. Diffing, resolving conflicts, and moving through file revisions (and a lot more).
masklinn 3y ago
> searching for a function I deleted > git log -G someFunc This will look for all changes mentioning someFunc throughout the history of the project. Usually -S is more valuable, as it will look for changes in occurrence counts. So if you moved a call in a commit -G will flag it, but -S will ignore it (+1-1 = 0). -S also defaults to fixed string, so no need for -F. Instead you need —pickaxe-regex to switch it to regex search.
tambourine_man 3y ago
If you’re a Vim user, fugitive by tpope is a great tool

by mbakke 3y ago

levidos 3y ago

Extremely handy, saving these. Thank you.

globular-toast 3y ago

Magit has a really easy to use way to "step" through previous versions of files. It's usually bound to something like "C-f p". You get a read only buffer of the previous version open in the best text editor (emacs). You can then press n and p to step through next and previous versions of that file. Can be pretty useful! It's kind of funny, I think, how most git users don't seem to know how to access any version other than the current one. So many people think of it simply as the annoying tool you have to use to make code changes but don't really know what version control is.

divbzero 3y ago
That’s a pretty cool feature of Magit. I was inspired to look for something similar for the next best text editor (vim) and came across this: https://salferrarello.com/using-vim-view-git-commits/ https://salferrarello.com/using-vim-view-git-commits/ git log | vim -R - Placing your cursor over a commit hash and entering K displays git show for that commit.
- cnity 3y ago
  If you're not using neovim you're really missing out right now IMO. It's a renaissance for a hackable text editor because it uses a sensible modern programming language (Lua) rather than vimscript (yikes) or elisp (eh).
  - globular-toast 3y ago
    You may be missing the point of Elisp. Elisp isn't an "extension language". It's the language Emacs is built with. When you run Emacs you're actually running a Lisp interpreter with a load of text editing features pre-loaded. When you eval some Lisp you're modifying the runtime, essentially live patching your editor in real time. So really any comparisons with Elisp are irrelevant unless you can do what it can do. Common Lisp and Scheme (Guile) are real contenders but the challenge is not giving up the enormous amount of useful code that is already written in Elisp.
    - galangalalgol 3y ago
      Does the elisp interpreter that runs emacs have jit?
      - fourthark 3y ago
        Only with v28, a year or two ago.
        klibertp 3y ago
        That's not a JIT. It uses `libgccjit` (IIRC the name), but the native code is produced ahead-of-time. JITs compile using info available on runtime, and native-comp doesn't do that. LuaJIT, by contrast, is a "real" JIT. Still, native-comp does speed things up considerably.
    - cnity 3y ago
      I'm a big lisp fan. I know about all of this, I used emacs for maybe a decade, and I still don't like elisp. I love the hackability of Emacs, but it's OK to dislike the language itself. Disliking semantic choices of the language doesn't mean I'm missing the point either! And on "it's not just an extensibility language": in my experience this doesn't matter. I get that "well the editor itself is half written in elisp" and so vaguely that is superior, but it is only so in an academic sense. Expose the primitives for the editor in some API in _any_ langauge and you can basically achieve the same thing anyway, so pick a language that doesn't make me want to poke my eyeballs out with a hot skewer. Sorry, rant over.
- sourcegrift 3y ago
  I've been told by my elders that when a vim user encounters an emacs supremacist, they must fight back. You can't just call it "the next best text editor". Jokes aside, As a vim user of 6 years, I did learn just enough emacs for magit (TM) and have also been making quick bucks on the side teaching it to my friends , so I guess I can't help with the "fight back" part :-)
- fiddlerwoaroof 3y ago
  Or I could use magit inside the best implementation of the vi standard.
masklinn 3y ago
My bread and butter is jumping via blame, though I don’t really like emacs’ blame view so I generally use intellij or git gui. e.g. see something odd / interesting, activate blame view, and “show diff” / “annotate previous revision” to see how the hunk evolved. Often this provides fast-tracking through the file’s history as the hunk goes through inconsequential changes (e.g. reformatting, minor updates) without changing the gist of what sparked your interest.
- fiddlerwoaroof 3y ago
  vc-annotate in emacs is my favorite blame view I’ve seen, if you haven’t tried it.
cnity 3y ago
Similarly with fugitive in vim, which is fantastic. Diffing, resolving conflicts, and moving through file revisions (and a lot more).

masklinn 3y ago

> searching for a function I deleted > git log -G someFunc This will look for all changes mentioning someFunc throughout the history of the project. Usually -S is more valuable, as it will look for changes in occurrence counts. So if you moved a call in a commit -G will flag it, but -S will ignore it (+1-1 = 0). -S also defaults to fixed string, so no need for -F. Instead you need —pickaxe-regex to switch it to regex search.

tambourine_man 3y ago

If you’re a Vim user, fugitive by tpope is a great tool