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

Supercharging the Git Commit Graph

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

31–40 of 87 posts

Re: Supercharging the Git Commit Graph

#31

Post by adrianN »

Aissen wrote: post #20
rakoo wrote: post #13

Yet another file in the .git directory. The work is impressive and certainly helpful, but I can already hear Fossil proponents say "just use SQLite", which is getting more and more true.

I had to bite… The sqlite repository has only 20795 commits since May 2000 at the time of this writing: https://www.sqlite.org/src/timeline?udc=1&ss=m&n=100000&y=ci This is the amount of commits that goes into Linux every ~5months. Has anyone done any meaningful performance comparison between fossil and git?

The number of commits is not a very meaningful metric.

Re: Supercharging the Git Commit Graph

#32

Post by masklinn »

farresito wrote: post #26
masklinn wrote: post #18

Earlier quoted context omitted.

How does it save time, given this command will rarely be run, and next version will automatically run it on GC? Instead of copy/pasting a command you now have to copy-paste that same command with more gunk added and run it separately.

You have to run it on every repository you want this in, don't you? At least, that's what I understood.

This is mostly for large repositories where building the revisions graph takes a long time (aka 5+ figures revisions). I have two of those from $dayjob, most of the stuff I work with/on/for doesn't come even remotely close. Running this on a repo with 5 commits is all but useless.

And even then you still really only need run it once per repository, you can just cd/paste/return; cd/paste/return; … Hell, you'd probably have an easier time writing a script which looks for all git repositories and runs the command versus having to manually visit each and do so.

Re: Supercharging the Git Commit Graph

#33

Post by masklinn »

adrianN wrote: post #31
Aissen wrote: post #20

Earlier quoted context omitted.

I had to bite… The sqlite repository has only 20795 commits since May 2000 at the time of this writing: https://www.sqlite.org/src/timeline?udc=1&ss=m&n=100000&y=ci This is the amount of commits that goes into Linux every ~5months. Has anyone done any meaningful performance comparison between fossil and git?

The number of commits is not a very meaningful metric.

It's very much a meaningful metric when the entire point of TFA is caching the commits graph. This is only an issue when you actually have lots of commits, and even more so a very branchy graph.

Re: Supercharging the Git Commit Graph

#35

Post by masklinn »

rakoo wrote: post #12
bluebluetimes wrote: post #8

To enable the commit-graph feature in your repository, run git config core.commitGraph true. Then, you can update your commit-graph file by running ‘git show-ref -s | git commit-graph write —stdin-commits' how do you automatically update this?

It's not perfect but doing it in a pre-push hook can be useful. Unfortunately there's no post-receive hook on client-side, which could have been useful in this situation...

> It's not perfect but doing it in a pre-push hook can be useful.

That's completely unnecessary and way too frequent. Some where else (reddit I think?) the authors noted that they'd like to have it run alongside GCs in the next version. So running it as pre-auto-gc is a better idea.

Re: Supercharging the Git Commit Graph

#36

Post by rakoo »

masklinn wrote: post #35
rakoo wrote: post #12

Earlier quoted context omitted.

It's not perfect but doing it in a pre-push hook can be useful. Unfortunately there's no post-receive hook on client-side, which could have been useful in this situation...

> It's not perfect but doing it in a pre-push hook can be useful. That's completely unnecessary and way too frequent. Some where else (reddit I think?) the authors noted that they'd like to have it run alongside GCs in the next version. So running it as pre-auto-gc is a better idea.

I was thinking that you need to do that everytime refs change, but it's just a boost and I presume you can have some refs in the commit-graph and some not in there and it will still work, so you're probably right.

Re: Supercharging the Git Commit Graph

#37

Post by adrianN »

masklinn wrote: post #33
adrianN wrote: post #31

Earlier quoted context omitted.

The number of commits is not a very meaningful metric.

It's very much a meaningful metric when the entire point of TFA is caching the commits graph. This is only an issue when you actually have lots of commits, and even more so a very branchy graph.

It's not a meaningful metric when discussing whether to use sqlite as storage for git instead of files in the .git directory.

Re: Supercharging the Git Commit Graph

#38

Post by superflyguy »

rakoo wrote: post #13

Yet another file in the .git directory. The work is impressive and certainly helpful, but I can already hear Fossil proponents say "just use SQLite", which is getting more and more true.

Use sqllite instead of git? Or git should use sqllite? If the latter then one problem is you'd need to keep your own fork forever as they don't accept patches. I'm not sure if that's a price worth paying to reduce the number of files git uses. Why is this a problem for you, anyway?

Re: Supercharging the Git Commit Graph

#39

Post by jasode »

adrianN wrote: post #37
masklinn wrote: post #33

Earlier quoted context omitted.

It's very much a meaningful metric when the entire point of TFA is caching the commits graph. This is only an issue when you actually have lots of commits, and even more so a very branchy graph.

It's not a meaningful metric when discussing whether to use sqlite as storage for git instead of files in the .git directory.

>It's not a meaningful metric when discussing whether to use sqlite as storage for git instead of files in the .git

There are 2 different conversations happening.

You seemed to be responding to ggp (rakoo) "sqlite db vs files".

However masklinn was responding to gp (Aissen) question of "Fossil vs Git" performance and a charitable reading would be comparing the Fossil algorithms (also affected by combination with underlying SQLite db engine algorithm) for commit searches, graph traversal, etc. In that case, the high number of commits and total repository size to stress test Fossil/Git would be very relevant.

An example post about Fossil scaling: https://www.fossil-scm.org/xfer/technote/be8f2f3447ef2ea3344...

Re: Supercharging the Git Commit Graph

#40

Post by rhencke »

rakoo wrote: post #13

Yet another file in the .git directory. The work is impressive and certainly helpful, but I can already hear Fossil proponents say "just use SQLite", which is getting more and more true.

I love SQLite, and Fossil is very cool, but I don't see the fundamental difference between Git adding another file in the .git directory, and Fossil adding another table or index in the SQLite database.
Post reply on HN