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

21–30 of 87 posts

Re: Supercharging the Git Commit Graph

#21

Post by naturalgradient »

rtcoolaid wrote: post #16
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.

Is that what you got from the article? Or you're the guy that knows the names of all he latest tools but understands the underlying concept of none and comments this making HN a waste of time to actually learn anything.

I think you should refrain from making such comments and follow the best-intention assumption on HN.

Re: Supercharging the Git Commit Graph

#22

Post by pdpi »

01100011 wrote: post #11
slobotron wrote: post #2

Interesting tidbit: > The developers making Microsoft Windows use Git

Kinda surprising. I know everyone seems to love git these days, but I find it's really better suited towards distributed and/or smaller projects. After feeling the pain of a megarepo system at work, I'm pushing to switch to a monorepo(well, like 4 repos instead of 200). git sort of sucks for monorepos. Also, even after learning a fair amount of git, I still find I spend a noticeable amount of time dealing with it. I…

> git sort of sucks for monorepos.

Microsoft works around several of the issues there by using GVFS. Also, at Microsoft scale, everything "sort of sucks", there's just no silver bullets. You take one of the least bad options and put all the effort you can towards making it work as well as you can.

Re: Supercharging the Git Commit Graph

#23

Post by gmueckl »

adrianN wrote: post #19
01100011 wrote: post #11

Earlier quoted context omitted.

Kinda surprising. I know everyone seems to love git these days, but I find it's really better suited towards distributed and/or smaller projects. After feeling the pain of a megarepo system at work, I'm pushing to switch to a monorepo(well, like 4 repos instead of 200). git sort of sucks for monorepos. Also, even after learning a fair amount of git, I still find I spend a noticeable amount of time dealing with it. I…

I do a lot of things that aren't really possible in older VCS with git, which is why I spent more time with it.

I don't do new things in git, but since we transitioned, I spend about 3 to 4 times longer wrestling the VCS than with anything that I have used previously. This is merely for routine stuff, because it takes more steps

Re: Supercharging the Git Commit Graph

#24

Post by stolee »

wscott wrote: post #17

"Before I joined Microsoft, I was a mathematician working in computational graph theory. I spent years thinking about graphs every day, so it was a habit that was hard to break. " As a former BitKeeper developer, this is a key person for Microsoft to have on hand to improve git. BitKeeper got about 10X faster after it was used on the Linux kernel and many of the key performance wins were due to better graph traversal…

Sorry for the worrying note about the experimental feature. One issue when working in open source is that contributors don't have control over the release cycle, and review requires smaller series than having the feature be delivered all at once.

These interactions with grafts, replace-objects, and shallow clones are one reason 2.18 does not create and manage this file automatically. The commit-graph file works by representing the commit relationships in a new file, and if that file exists, we treat that as the truth. The commit grafts, replace-objects, and shallow clones use another set of special files to track commits whose parents have been modified in special ways. If you would like to see our progress on integrating these features together, please see this thread on the Git mailing list: https://public-inbox.org/git/20180531174024.124488-1-dstolee...

Re: Supercharging the Git Commit Graph

#25

Post by stolee »

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?

We are working to make this run automatically in the future. https://public-inbox.org/git/20180627132447.142473-1-dstolee...

You don't need to run this with every commit, but maybe once after a big fetch or right after a new clone.

Re: Supercharging the Git Commit Graph

#26

Post by farresito »

masklinn wrote: post #18
farresito wrote: post #14

To save people some time, an alias for your .gitconfig create-graph = "!f() { git show-ref -s | git commit-graph write --stdin-commits ; } ; f"

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.

Re: Supercharging the Git Commit Graph

#27

Post by wscott »

stolee wrote: post #24
wscott wrote: post #17

"Before I joined Microsoft, I was a mathematician working in computational graph theory. I spent years thinking about graphs every day, so it was a habit that was hard to break. " As a former BitKeeper developer, this is a key person for Microsoft to have on hand to improve git. BitKeeper got about 10X faster after it was used on the Linux kernel and many of the key performance wins were due to better graph traversal…

Sorry for the worrying note about the experimental feature. One issue when working in open source is that contributors don't have control over the release cycle, and review requires smaller series than having the feature be delivered all at once. These interactions with grafts, replace-objects, and shallow clones are one reason 2.18 does not create and manage this file automatically. The commit-graph file works by re…

> One issue when working in open source is that contributors don't have control over the release cycle, and review requires smaller series than having the feature be delivered all at once.

Yes, my reply was unnecessarily disparaging. Overall this looks like a cool feature. Perhaps a stopgap solution if for those commands to just delete your cache. But then your repository will get mysteriously slower. I just need to think of this as a technology demonstration.

Re: Supercharging the Git Commit Graph

#28

Post by stolee »

wscott wrote: post #27
stolee wrote: post #24

Earlier quoted context omitted.

Sorry for the worrying note about the experimental feature. One issue when working in open source is that contributors don't have control over the release cycle, and review requires smaller series than having the feature be delivered all at once. These interactions with grafts, replace-objects, and shallow clones are one reason 2.18 does not create and manage this file automatically. The commit-graph file works by re…

> One issue when working in open source is that contributors don't have control over the release cycle, and review requires smaller series than having the feature be delivered all at once. Yes, my reply was unnecessarily disparaging. Overall this looks like a cool feature. Perhaps a stopgap solution if for those commands to just delete your cache. But then your repository will get mysteriously slower. I just need to…

The good news is that if you are using shallow clones, then you probably don’t have enough commits locally to need the commit-graph feature!

Re: Supercharging the Git Commit Graph

#29

Post by adrianN »

gmueckl wrote: post #23
adrianN wrote: post #19

Earlier quoted context omitted.

I do a lot of things that aren't really possible in older VCS with git, which is why I spent more time with it.

I don't do new things in git, but since we transitioned, I spend about 3 to 4 times longer wrestling the VCS than with anything that I have used previously. This is merely for routine stuff, because it takes more steps

The additional steps enable workflows that weren't possible before, so it's a tradeoff.

Re: Supercharging the Git Commit Graph

#30

Post by yoklov »

fanf2 wrote: post #7
yoklov wrote: post #3

Dang, this made `git log` inside the repo I use at work (which is enormous with a stupid number of commits) nearly instantaneous. Great work. `git status` still takes over a second for me though, oh well...

Have you tried the fsmonitor hook feature that was added in git 2.17? https://blog.github.com/2018-04-05-git-217-released/

Yep, as well as the untracked cache. I also was using a split index for a while, but it didn’t play nicely with some tools...
Post reply on HN