@ -16,7 +16,7 @@ Over the years I've greatly enjoyed learning how to simplify common actions in t
I found myself in a situation last week where I wanted to quickly reopen all the files from my last Git commit. It's easy to do this, but in my experience one of the difficulties of Bash is knowing what keywords to search for to find help, so I'm going to put the pieces of this together one by one, with some other helpful tricks, so that you don't have to wait as long to find each piece as I did.
## Command Substitution
One feature of Bash that I took far too long to fully discover and understand, but now can't live without, is command substitution. In short, it's a shortcut to simplify using the output of evaluating a command as input to some other command. This is possible with pipes, but often more verbose. The short form is simple -- `$(command)`. For example, one might be looking around for something in a project dir with `rg`[^1] - `rg 'function_name'` - and then decide it's time to edit. `rg` lists matching files with the `-l` switch, so you can invoke `vim $(rg -l 'function_name')` to open all the search results as vim buffers. This could be shortened or further manipulated with history commands. I've found a good quick-reference for those on StackExchange[^2];do yourself a favor and give it a look if you aren't familiar, but I won't go into detail here as we're already getting a bit afield.
It took me a while to wrap my head around command substitution, but now it's a Bash feature I can't live without. In short, it's a shortcut to simplify using the output of evaluating a command as input to some other command. This is possible with pipes, but often more verbose. The short form is simple -- `$(command)`. For example, one might be looking around for something in a project dir with `rg`[^1] - `rg 'function_name'` - and then decide it's time to edit. `rg` lists matching files with the `-l` switch, so you can invoke `vim $(rg -l 'function_name')` to open all the search results as vim buffers.[^2]
## Listing files from a commit
So, if we have a command that can produce a list of files from the last commit with no other data, we know how to easily bring them into vim. Luckily we have options! When I set this up I definitely just found the relevant StackOverflow[^3] and ran with it, but I hate to miss an opportunity to recommend spending some time with the Git docs[^4], where with a little determination and trial-and-error you could find your way to the right answer as well. The recommended answer that we'll use here is: `git diff-tree --no-commit-id --name-only -r <commit-ish>`
@ -26,9 +26,9 @@ Now it's almost as simple as combining those two pieces! Yes, `vim $(git diff-tr
I don't know if there's a more recommended or standard way to organize scripts like this[^5], but my approach is to make a dir at `~/scripts` and make sure it's on my `$PATH`. So, we'll put this little buddy at `~/scripts/edit_last_commit`.
The only other detail to comment on here is one I've elided so far: how to refer to whatever set of changed files we want to edit. What I'm getting at is, what is a <commit-ish>? It's... something that looks kinda like a commit! For a very detailed explanation we can turn again to the Git documentation[^6] but in short, most any way of identifying "the set of files last changed *here*" will work.
The only other detail to comment on here is one I've elided so far: how to refer to whatever set of changed files we want to edit. What I'm getting at is, what is a <commit-ish>? It's... something that looks kinda like a commit! For a very detailed explanation we can turn again to the Git documentation[^6] but in short, most any way of identifying "the set of files last changed *here*" should work.
That's a lot of bits and bobs! I hope at least one of them is new and useful to you. Let's put them all into a bash script, with some annotation:
OK. Let's roll this all into a bash script, with some annotation:
```bash
#!/bin/bash # shebang line to ensure we end up evaluating this as bash!
@ -54,7 +54,7 @@ I have called this script "simple" but it's only simple to me because I've spent
[^1]: [ripgrep, my current favorite grep-alike](https://github.com/BurntSushi/ripgrep)
[^2]: [What are your favorite command line features or tricks? - Unix & Linux StackExchange](https://unix.stackexchange.com/questions/6/what-are-your-favorite-command-line-features-or-tricks/67#67)
[^2]: This could be shortened or further manipulated with history commands. Here's a good quick-reference for those on StackExchange: [What are your favorite command line features or tricks? - Unix & Linux StackExchange](https://unix.stackexchange.com/questions/6/what-are-your-favorite-command-line-features-or-tricks/67#67)
[^3]: [How to list all the files in a commit? - StackOverflow](https://stackoverflow.com/questions/424071/how-to-list-all-the-files-in-a-commit)
[^4]: I find that I'm constantly re-learning the value of spending some time reading documentation, manual pages, etc. for commonly used tools - for me, recently this means git, tmux, and vim - so, here's the [Git Book section on viewing commit history](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History), and I strongly recommend taking some time now and then to read up on the amazing tools at your disposal!
