Re: [PATCH v6 00/14] Serialized Git Commit Graph

On 3/19/2018 8:55 AM, Derrick Stolee wrote: Thanks for this! Fixing this performance problem is very important to me, as we will use the "--stdin-packs" mechanism in the GVFS scenario (we will walk all commits in the prefetch packs full of commits and trees instead of relying on refs). This

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On 3/16/2018 12:28 PM, Lars Schneider wrote: On 14 Mar 2018, at 21:43, Junio C Hamano wrote: Derrick Stolee writes: Hopefully this version is ready to merge. I have several follow-up topics in mind to submit soon after, including: A few patches add

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On 3/16/2018 4:19 PM, Jeff King wrote: On Fri, Mar 16, 2018 at 04:06:39PM -0400, Jeff King wrote: Furthermore, in order to look at an object it has to be zlib inflated first, and since commit objects tend to be much smaller than trees and especially blobs, there are a lot less bytes to

Re: [PATCH v6 00/14] Serialized Git Commit Graph

Hi Junio, On Fri, 16 Mar 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > I understand that it is a trade-off between time you have to spend and > > that others have to spend, and since you do not scale, that trade-off > > has to be in your favor. >

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On Fri, Mar 16, 2018 at 11:33:55AM -0700, Junio C Hamano wrote: > It is not so surprising that history walking runs rings around > enumerating objects in packfiles, if packfiles are built well. > > A well-built packfile tends to has newer objects in base form and > has delta that goes in

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On Fri, Mar 16, 2018 at 04:06:39PM -0400, Jeff King wrote: > > Furthermore, in order to look at an object it has to be zlib inflated > > first, and since commit objects tend to be much smaller than trees and > > especially blobs, there are a lot less bytes to inflate: > > > > $ grep ^commit

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On Fri, Mar 16, 2018 at 7:33 PM, Junio C Hamano wrote: > SZEDER Gábor writes: > >> You should forget '--stdin-packs' and use '--stdin-commits' to generate >> the initial graph, it's much faster even without '--additive'[1]. See >> >> >>

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On Fri, Mar 16, 2018 at 08:48:49PM +0100, SZEDER Gábor wrote: > I came up with a different explanation back then: we are only interested > in commit objects when creating the commit graph, and only a small-ish > fraction of all objects are commit objects, so the "enumerate objects in > packfiles"

Re: [PATCH v6 00/14] Serialized Git Commit Graph

SZEDER Gábor writes: > You should forget '--stdin-packs' and use '--stdin-commits' to generate > the initial graph, it's much faster even without '--additive'[1]. See > > > https://public-inbox.org/git/CAM0VKj=wmkBNH=pscrztxfrc13rig1easw89q6ljansdjde...@mail.gmail.com/

Re: [PATCH v6 00/14] Serialized Git Commit Graph

Johannes Schindelin writes: >> > Stolee, you definitely want to inspect those changes (`git log --check` >> > was introduced to show you whitespace problems). If all of those >> > whitespace issues are unintentional, you can fix them using `git rebase >> >

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On Fri, Mar 16, 2018 at 4:06 PM, Ævar Arnfjörð Bjarmason wrote: > I noticed that it takes a *long* time to generate the graph, on a bigger > repo I have it takes 20 minutes, and this is a repo where repack -A -d > itself takes 5-8 minutes, probably on the upper end of that with

Re: [PATCH v6 00/14] Serialized Git Commit Graph

> On 14 Mar 2018, at 21:43, Junio C Hamano wrote: > > Derrick Stolee writes: > >> This v6 includes feedback around csum-file.c and the rename of hashclose() >> to finalize_hashfile(). These are the first two commits of the series, so >> they could be

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On Wed, Mar 14 2018, Derrick Stolee jotted: > Hopefully this version is ready to merge. I have several follow-up topics > in mind to submit soon after, including: I've been doing some preliminary testing of this internally, all good so far, on a relatively small repo (~100k commits) I was using

Re: [PATCH v6 00/14] Serialized Git Commit Graph

Hi Junio, On Thu, 15 Mar 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Stolee, you definitely want to inspect those changes (`git log --check` > > was introduced to show you whitespace problems). If all of those > > whitespace issues are

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On 15/03/18 18:41, Junio C Hamano wrote: > Johannes Schindelin writes: > >> Stolee, you definitely want to inspect those changes (`git log --check` >> was introduced to show you whitespace problems). If all of those >> whitespace issues are unintentional, you can

Re: [PATCH v6 00/14] Serialized Git Commit Graph

Johannes Schindelin writes: > Stolee, you definitely want to inspect those changes (`git log --check` > was introduced to show you whitespace problems). If all of those > whitespace issues are unintentional, you can fix them using `git rebase > --whitespace=fix` in

Re: [PATCH v6 00/14] Serialized Git Commit Graph

Hi Junio, On Wed, 14 Mar 2018, Junio C Hamano wrote: > A few patches add trailing blank lines and other whitespace > breakages, which will stop my "git merge" later to 'next' and down, > as I have a pre-commit hook to catch them. I wonder how you cope with the intentional "whitespace breakage"

Re: [PATCH v6 00/14] Serialized Git Commit Graph

Derrick Stolee writes: > This v6 includes feedback around csum-file.c and the rename of hashclose() > to finalize_hashfile(). These are the first two commits of the series, so > they could be pulled out independently. > > The only other change since v5 is that I re-ran the

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On 14/03/18 19:27, Derrick Stolee wrote: > This v6 includes feedback around csum-file.c and the rename of hashclose() > to finalize_hashfile(). These are the first two commits of the series, so > they could be pulled out independently. > > The only other change since v5 is that I re-ran the