I wonder about which primary branch naming convention they’ll arrive at. “primary” is my personal favorite ;)
I miss trunk.
Highlights from Git 2.28
11–20 of 147 posts
Re: Highlights from Git 2.28
#12Someone please give me the missing link here: 1. I do `git log` which helpfully pipes to `more` where I can use vim-stsyle search to find the commit I'm interested in. 2. I find the relevant commit. 3. Now I want to `git show` that commit. Currently I double click on the human unreadable commit, copy it, quit `more` to get back to the command line, type `git show`, then paste the commit. Navigate, click-click, shortc…
By using a smarter tool.
I personally use magit, which solves this problem across all of git, but it's tied to Emacs.
tig is a git log browser I've heard good things about that seems to handle this use case very nicely.
You may also be able to pervert less into making this easier, e.g. by using lesskey(1) to add a keybinding that runs `git show $(xclip -o)`. I don't know how wise that would be.
Re: Highlights from Git 2.28
#13I wonder about which primary branch naming convention they’ll arrive at. “primary” is my personal favorite ;)
As someone who learnt version control with Subversion, I'm hoping trunk will come back into fashion.
Re: Highlights from Git 2.28
#14I wonder about which primary branch naming convention they’ll arrive at. “primary” is my personal favorite ;)
At Elementary we've adopted `latest` as it tracks nicely with the bleeding-edge tag for Docker containers which we don't have control over. This way, when we build/deploy containers off of the `latest` branch there's an equivalent tag on our DockerHub repos.
Re: Highlights from Git 2.28
#15Someone please give me the missing link here: 1. I do `git log` which helpfully pipes to `more` where I can use vim-stsyle search to find the commit I'm interested in. 2. I find the relevant commit. 3. Now I want to `git show` that commit. Currently I double click on the human unreadable commit, copy it, quit `more` to get back to the command line, type `git show`, then paste the commit. Navigate, click-click, shortc…
If you are using Tmux, you can use thmux-fingers[1] or tmux-thumbs[2], both create Vimium like shortchuts for urls and git hashes that once pressed copy the link to clipboard or the tmux buffer. Then you can just `git show` and `Ctrl-shift-V` or `Ctrl-b ]`. There's a lot of resources that can be yanked with tmux-fingers, kubernetes resources, ips and others
Re: Highlights from Git 2.28
#16Re: Highlights from Git 2.28
#17> [1] Note that since Bloom filters are not persisted automatically (that is, you have to pass --changed-paths explicitly on each subsequent write), it is a good idea to disable configuration that automatically generates commit-graphs, like fetch.writeCommitGraph and gc.writeCommitGraph.
Not sure I understand this note
Does this mean that:
git commit-graph write --reachable --changed-paths
Re: Highlights from Git 2.28
#18> [1] Note that since Bloom filters are not persisted automatically (that is, you have to pass --changed-paths explicitly on each subsequent write), it is a good idea to disable configuration that automatically generates commit-graphs, like fetch.writeCommitGraph and gc.writeCommitGraph. Not sure I understand this note Does this mean that: git commit-graph write --reachable --changed-paths is not a persistent setting…
The data is stored in your `commit-graph` file by this command, but those other ways to update the `commit-graph` file don't pay attention to the fact that the data exists in order to persist it.
There is work in progress to fix that issue, hopefully in the next version: https://lore.kernel.org/git/f1e3a8516ebd58b283166a5374843f5c...
Re: Highlights from Git 2.28
#19Someone please give me the missing link here: 1. I do `git log` which helpfully pipes to `more` where I can use vim-stsyle search to find the commit I'm interested in. 2. I find the relevant commit. 3. Now I want to `git show` that commit. Currently I double click on the human unreadable commit, copy it, quit `more` to get back to the command line, type `git show`, then paste the commit. Navigate, click-click, shortc…
I use FZF for this. It lets me do an incremental search on fit commit messages and show the diff of the selected commit. It’s a slightly customised version of fshow_preview from this example:
Re: Highlights from Git 2.28
#20Someone please give me the missing link here: 1. I do `git log` which helpfully pipes to `more` where I can use vim-stsyle search to find the commit I'm interested in. 2. I find the relevant commit. 3. Now I want to `git show` that commit. Currently I double click on the human unreadable commit, copy it, quit `more` to get back to the command line, type `git show`, then paste the commit. Navigate, click-click, shortc…
You could use `git log -p` instead of `git log` so that the diff is included.
To navigate efficiently between the commits, you could pre-seed less with a regex that matches commit (and file) lines, so that "n" and "N" jump from one commit (or file) to the next, something like this
LESS="-R --pattern ^(commit|diff) " git log -p
[1] https://github.com/dandavison/delta
(Disclosure: I am the author of delta)