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

81–87 of 87 posts

Re: Supercharging the Git Commit Graph

#81

Post by bzbarsky »

DaiPlusPlus wrote: post #60
erik_seaberg wrote: post #54

Earlier quoted context omitted.

Untested commits should never exist, so why are we creating commits from abstracted storage that can't even be built and tested? Staging should happen in the workspace, stashing stuff that's not ready to commit.

> Untested commits should never exist Says who? Branches and commits are cheap, it's how we can undo ourselves and freely experiment. I agree that untested commits into a publishing/release branch shouldn't exist: all commits there should be merges from dev branches, but to say every commit should be tested is utter bollocks and denies us the advantages of cheap branching and commits.

> all commits there should be merges from dev branches

Either they need to be squash+merge or the dev branches need to end up with working commits before the merge. Otherwise your life will become hell the first time you need to bisect.

Re: Supercharging the Git Commit Graph

#82

Post by SQLite »

WorldMaker wrote: post #78
rakoo wrote: post #72

Earlier quoted context omitted.

Fossil itself is stored entirely inside a SQLite db and only uses it to do everything it needs; if Fossil can do it, any VCS can do it. In fact, there is a whole section on that point in the official SQLite page ( https://www.sqlite.org/lang_with.html#rcex2 ). I'm not saying SQL is the best way to store and query DAGs; any graph database would be better. All I'm saying is that SQL is probably better at designing and…

But you are also almost intentionally confusing the SQL standard here in your comment with the SQLite implementation (a de facto standard, of a sort, but not a recognized standard by any body of peers to my knowledge) with SQLite's particular binary format (which does change between versions even). That is a custom file format with custom code. Certainly it is very portable custom code, as SQLite is open source and p…

> SQLite [is] not a recognized standard by any body of peers to my knowledge...

Well, there is this: https://www.loc.gov/preservation/resources/rfs/data.html

Also, the on-disk format for SQLite has been extended, but has not fundamentally changed since version 3.0.0 was released on 2004-06-18. SQLite version 3.0.0 can still read and write database files created by the latest release, as long as the database does not use any of the newer features. And, of course, the latest release of SQLite can read/write any database. There are over a trillion SQLite databases in active use in the wild, and so it is important to maintain backwards compatibility. We do test for that.

The on-disk format is well-documented (https://sqlite.org/fileformat2.html) and multiple third parties have used that document to independently create software that both reads and writes SQLite database files. (We know this because they have brought ambiguities and omissions to our attention - all of which have now been fixed.)

Re: Supercharging the Git Commit Graph

#83

Post by vhbit »

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…

Off topic: considering you've left BitKeeper and you were one of the most active developers in user forum, what's the status of BitKeeper? Is it still developed* or it's in maintenance mode for existing commercial clients?

* yes, it's open source, but being open source and "you can add any feature yourself" doesn't imply there is a momentum behind and a kind of "directed" force to move it forward

Re: Supercharging the Git Commit Graph

#84

Post by Aissen »

reificator wrote: post #47
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?

How does the number of commits in the SQLite repository make it unsuitable as alternate store for git metadata?

@jasode's reply in this thread made a good summary of the two parallel discussions/quid pro quo:

- on filesystem vs sqlite (put git files in sqlite): there's a good benchmark on https://www.sqlite.org/fasterthanfs.html claiming sqlite is up to 35% faster than fs. I'd like to see the same benchmark with git's file pattern; also, it's a known issue with git that it was written for linux first, hence optimized against Linux (relatively) good fs performance (vs Windows and Mac at the time). Same with most OSS build systems that (over)use process forking, which is also very optimized in Linux.

- on Fossil vs git (why bother putting git files in sqlite and not directly jump to fossil?): that was my comment, and it relates to subject of this article (the commit-graph). I'm wondering if Fossil has seen the optimization that git has, with regards to number of commits, considering that sqlite is the only high-profile project that uses it. Maybe performance is supposed to be taken care of by the sqlite database itself ?

Edit: see https://www.fossil-scm.org/xfer/doc/trunk/www/stats.wiki for a fossil-provided performance analysis, that does a comparison with CVS (!).

Re: Supercharging the Git Commit Graph

#85

Post by [deleted] »

masklinn wrote: post #32
farresito wrote: post #26

Earlier quoted context omitted.

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…

[deleted]

Re: Supercharging the Git Commit Graph

#86

Post by [deleted] »

Aissen wrote: post #84
reificator wrote: post #47

Earlier quoted context omitted.

How does the number of commits in the SQLite repository make it unsuitable as alternate store for git metadata?

@jasode's reply in this thread made a good summary of the two parallel discussions/quid pro quo: - on filesystem vs sqlite (put git files in sqlite): there's a good benchmark on https://www.sqlite.org/fasterthanfs.html claiming sqlite is up to 35% faster than fs. I'd like to see the same benchmark with git's file pattern; also, it's a known issue with git that it was written for linux first, hence optimized against L…

[deleted]
Post reply on HN