Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Highlights from Git 2.28

github.blog

Post reply on HN
Print view View original

21–30 of 147 posts

Re: Highlights from Git 2.28

#21

Post by wyldfire »

jancsika wrote: post #9

Someone 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 can also do `git log -p`. It includes the diff inline. Takes more time to search a long history but omits the extra manual steps.

Re: Highlights from Git 2.28

#22

Post by platz »

stolee wrote: post #18
platz wrote: post #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 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...

so, then if I want to run

    git log -- /path/to/file
I should always execute

     git commit-graph write --reachable --changed-paths
first, if i've made any changes to the repo (e.g. commits), since the last time i've run it (unless I disable the configuration that automatically generates commit-graphs with fetch.writeCommitGraph and gc.writeCommitGraph) ?

Re: Highlights from Git 2.28

#23

Post by kemitche »

jancsika wrote: post #9

Someone 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…

Would `git log --grep='some pattern'` help? Or perhaps since you're searching, "git log -p" (or other flags) to have the log show the data you need inline rather then needing to separately run "git show".

Re: Highlights from Git 2.28

#24

Post by palsir »

solatic wrote: post #8
Twisol wrote: post #3

Earlier quoted context omitted.

I saw somebody on Twitter call theirs "canon", which I've really taken a liking to. It fits nicely in regular speech too :D

Canon is excellent, but I fear it wouldn't catch on due to its religious origins / connotations.

what are the religious origins/connotations? That various religions also have a canon and apocrypha?

Re: Highlights from Git 2.28

#25

Post by arp242 »

pojntfx wrote: post #2

I wonder about which primary branch naming convention they’ll arrive at. “primary” is my personal favorite ;)

It's rather hard to type as it's switching hands a lot; both "master" and "main" are easier to type, and are also shorter (as least "main" would be an improvement in that sense; "primary" would be quite the regression IMO).

Re: Highlights from Git 2.28

#27

Post by jancsika »

Myrmornis wrote: post #20
jancsika wrote: post #9

Someone 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 Delta[1] makes this convenient: delta --navigate. [1] https://github.com/dandavison/delta (…

Ooh, thanks. I think I can get away with git log -p to fetch the whole enchilada.

There are just so many things in the git CLI that are a single step away from being usable by default. For example, in Gitlab by default you see a tag to let you know if a branch has been merged. I can do the same in cli by exploring my flag options, but that time adds up for every little convenience that happens to be missing. (And as Gitlab shows, it's not impossible to choose a set of default conveniences that cover the bases for an enormous percentage of the users.)

I'll definitely look into that jumping pattern, too. Thanks for the hints!

Re: Highlights from Git 2.28

#28

Post by stolee »

platz wrote: post #22
stolee wrote: post #18

Earlier quoted context omitted.

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...

so, then if I want to run git log -- /path/to/file I should always execute git commit-graph write --reachable --changed-paths first, if i've made any changes to the repo (e.g. commits), since the last time i've run it (unless I disable the configuration that automatically generates commit-graphs with fetch.writeCommitGraph and gc.writeCommitGraph) ?

If you don't disable fetch.writeCommitGraph and gc.writeCommitGraph there is a chance that those operations will overwrite your commit-graph and delete the changed-path filter data. (fetch.writeCommitGraph uses the --split option so it might not actually erase the data until you have accumulated enough "new" commits)

You don't need to rewrite the commit-graph file every time you want to run "git log". The "git log" command will parse the newer commits the old-fashioned way until you reach the commits encoded in the commit-graph file. If you do it once now, then you'll still be fast even if a few commits are added on top of your existing history.

If you update the commit-graph with that command once a week, then you'll stay fast even in a very large repository.

Re: Highlights from Git 2.28

#29

Post by platz »

stolee wrote: post #28
platz wrote: post #22

Earlier quoted context omitted.

so, then if I want to run git log -- /path/to/file I should always execute git commit-graph write --reachable --changed-paths first, if i've made any changes to the repo (e.g. commits), since the last time i've run it (unless I disable the configuration that automatically generates commit-graphs with fetch.writeCommitGraph and gc.writeCommitGraph) ?

If you don't disable fetch.writeCommitGraph and gc.writeCommitGraph there is a chance that those operations will overwrite your commit-graph and delete the changed-path filter data. (fetch.writeCommitGraph uses the --split option so it might not actually erase the data until you have accumulated enough "new" commits) You don't need to rewrite the commit-graph file every time you want to run "git log". The "git log" c…

> The "git log" commit will parse the newer commits the old-fashioned way until you reach the commits encoded in the commit-graph file. If you do it once now, then you'll still be fast even if a few commits are added on top of your existing history.

Thanks, this is the context I was missing.

Just wanted to avoid a "dirty read" situation.

Thank you for providing the answers here- very helpful!

Re: Highlights from Git 2.28

#30

Post by jayd16 »

I just came back to git and gitlab from Perforce and while it's felt like coming home and some things are improving around submodules and LFS there's still a lot of rough edges I'd like to see smoothed over.

Its not easy to set up git config settings for a distributed team. I assume for security reasons a repo can't configure its own settings just from a pull but even still I want that functionality.

Why do I check in the name of the merge tool used for a file type in the .gitattributes but I can't check in what that name points to?

I work with less technical artists and they really don't want to think about git configs at all. They just want to save and push. As far as I know there's no solution to preconfigure a repo to pull submodules or set up custom merge drivers. Best thing I've found is to maintain repo setup scripts but its pretty cumbersome and you have to manually target the tools you want to support.

Is there a way to request this sort of stuff or a place to look at roadmaps without getting into the whole mailing list scene?

Maybe this sort of thing should be the responsibility of github/gitlab and not git itself?

Post reply on HN