Re: [PATCH v3 0/6]

Junio C Hamano gitster at pobox.com writes: This is mostly unchanged since the previous round, except that * The option is spelled --force-with-lease=ref:expect. Nobody liked cas as it was too technical, many disliked lockref because lock sounded as if push by others were

Re: How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)

Jens Müller blog at tessarakt.de writes: Hi all! I mainly use Git for version control, but have also tried out Mercurial. While I don't really like Mercurial in general, the idea of maintaining clearly separated patches with Mercurial Queues (MQ) is quite appealing. Therefore, I am

Re: [PATCH] gitweb: URL-decode $my_url/$my_uri when stripping PATH_INFO

/gitweb-lib.sh allows to set PATH_INFO and QUERY_STRING, but does not allow to set up URL. That might change in the future... Jakub, Ack? Acked-by: Jakub Narebski jna...@gmail.com Uf ut us bot too late... -- Jakub Narebski Poland -- To unsubscribe from this list: send the line unsubscribe git

Re: Git exile Issues

Sudhir Kumar smalikphy at gmail.com writes: Hey Git Experts, I need your advice. I have lot of png/jpg images in my codebase (which is currently under git) which causes the repo size to be very heavy. We have migrated these images to a storage server using git exile technique. This has

Re: What's cooking in git.git (Jun 2013, #04; Tue, 11)

Junio C Hamano gitster at pobox.com writes: * rr/remove-contrib-some (2013-06-02) 1 commit (merged to 'next' on 2013-06-05 at fc15705) + contrib: remove continuous/ and patches/ Remove stale contrib/ material. Will merge to 'master'. What about contrib/blameview by Aneesh Kumar K.V

Re: [PATCH] instaweb: make the perl path configurable

Charles McGarvey chazmcgarvey at brokenzipper.com writes: It is convenient for the user to be able to customize the path to perl if they do not want to use the system perl. This may be the case, for example, if the user wants to use the plackup httpd but its extra dependencies are not

Re: Exact format of tree objets

Junio C Hamano gitster at pobox.com writes: Chico Sokol chico.sokol at gmail.com writes: Is there any official documentation of tree objets format? Are tree objects encoded specially in some way? How can I parse the inflated contents of a tree object? We're suspecting that there is

Re: [PATCH] Documentation/CommunityGuidelines

Philip Oakley philipoakley at iee.org writes: From: Michael Haggerty mhagger at alum.mit.edu Sent: Tuesday, June 11, 2013 7:52 PM As my mother would say, politeness costs nothing Does your mother program C? We could use her around here I think she programmed in Smalltalk and

Re: Feature request:

[I'm sorry about breaking Cc: chain - responding via GMane web interface] Junio C Hamano gitster at pobox.com writes: Ed Hutchins eh at demeterr.com writes: I'm not trying to change the way git does things (which works perfectly well), I'm asking for some extra information to be added to

Re: [PATCH] RelNotes/1.8.5: direct script writers to git status --porcelain

easier to parse and stable, + instead. Good addition. Perhaps to use instead ... would be easier to understand than proposed to use ..., instead. (with ... being one line long). -- Jakub Narebski. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message

Re: Setting per-repository configuration for git

Jeff King peff at peff.net writes: On Fri, Oct 25, 2013 at 09:12:35AM +0200, Jeremy Rosen wrote: however I can't find a way to have the repository's configuration saved and transmited with the repository in a way similar to how .gitignore is transmitted... [...] Two, the config is

Re: How to resume broke clone ?

zhifeng hu zf at ancientrocklab.com writes: Once using git clone —depth or git fetch —depth, While you want to move backward. you may face problem git fetch --depth=105 error: Could not read 483bbf41ca5beb7e38b3b01f21149c56a1154b7a error: Could not read

Re: [PATCH v2 09/10] builtin/replace: unset read_replace_refs

Christian Couder chriscool at tuxfamily.org writes: When checking to see if some objects are of the same type and when displaying the type of objects, git replace uses the sha1_object_info() function. Unfortunately this function by default respects replace refs, so instead of the type of

[RFC] Other chunks for commit-graph, part 2 - reachability indexes

Hello, In previous email I wrote: JN> As this post is getting long, I'll post other ideas, about commit JN> labeling for faster reachability queries in a separate email. This is this email. Here is second part of series dedicated to discussing what other data, like various reachability

[RFC] Other chunks for commit-graph, part 1 - Bloom filters, topo order, etc.

Hello, With early parts of commit-graph feature (ds/commit-graph and ds/lazy-load-trees) close to being merged into "master", see https://public-inbox.org/git/xmqq4ljtz87g@gitster-ct.c.googlers.com/ I think it would be good idea to think what other data could be added there to make Git even

Re: [RFC] Other chunks for commit-graph, part 1 - Bloom filters, topo order, etc.

Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > On Fri, May 04 2018, Jakub Narebski wrote: > > (Just off-the cuff here and I'm surely about to be corrected by > Derrick...) > >> * What to do about merge commits, and octopus merges in particular? >> Shoul

Re: [RFC] Other chunks for commit-graph, part 1 - Bloom filters, topo order, etc.

Derrick Stolee <sto...@gmail.com> writes: > On 5/12/2018 10:00 AM, Jakub Narebski wrote: >> Derrick Stolee <sto...@gmail.com> writes: >>> On 5/4/2018 3:40 PM, Jakub Narebski wrote: >>>> >>>> With early parts of commit-graph feature (ds/co

Re: [PATCH v4 04/10] commit: use generations in paint_down_to_common()

Jakub Narebski <jna...@gmail.com> writes: > Junio C Hamano <gits...@pobox.com> writes: >> Derrick Stolee <dsto...@microsoft.com> writes: [...] >>> +int compare_commits_by_gen_then_commit_date(const void *a_, const void >>> *b_, void *unused) >&g

Re: [RFC] Other chunks for commit-graph, part 1 - Bloom filters, topo order, etc.

Derrick Stolee <sto...@gmail.com> writes: > On 5/4/2018 3:40 PM, Jakub Narebski wrote: >> >> With early parts of commit-graph feature (ds/commit-graph and >> ds/lazy-load-trees) close to being merged into "master", see >> https://public-inbox.org/git

Re: [PATCH 00/12] Die commit->util, die!

Nguyễn Thái Ngọc Duy writes: > There's not much to write here. It's basically a copy from 12/12: > > This 'util' pointer can be used for many different purposes, > controlled in different ways. Some are not even contained in a command > code, but buried deep in common code

Re: [PATCH v2 01/12] commit-graph: add 'verify' subcommand

Derrick Stolee writes: > If the commit-graph file becomes corrupt, we need a way to verify > that its contents match the object database. In the manner of > 'git fsck' we will implement a 'git commit-graph verify' subcommand > to report all issues with the file. > > Add

Re: [PATCH v2 02/12] commit-graph: verify file header information

Derrick Stolee writes: > During a run of 'git commit-graph verify', list the issues with the > header information in the commit-graph file. Some of this information > is inferred from the loaded 'struct commit_graph'. Some header > information is checked as part of

Re: [PATCH v2 03/12] commit-graph: test that 'verify' finds corruption

Derrick Stolee writes: > Add test cases to t5318-commit-graph.sh that corrupt the commit-graph > file and check that the 'git commit-graph verify' command fails. These > tests verify the header and chunk information is checked carefully. > > Helped-by: Martin Ågren

Re: commit-graph: change in "best" merge-base when ambiguous

Derrick Stolee writes: > On 5/22/2018 1:39 AM, Michael Haggerty wrote: >> On 05/21/2018 08:10 PM, Derrick Stolee wrote: >>> [...] >>> In the Discussion section of the `git merge-base` docs [1], we have the >>> following: >>> >>>     When the history involves criss-cross merges,

Re: [RFC PATCH 3/6] commit-graph: enable replace-object and grafts

Derrick Stolee writes: First, this commit seems to try to do two things at once, and in its current form it should be split into adding destroy_commit_graph() and into grafts / replacements check. Those are separate and unconnected features, and should be in separate patches, in my opinion. >

Re: [RFC PATCH 0/6] Fix commit-graph/graft/replace/shallow combo

Derrick Stolee writes: > The commit-graph file stores a condensed version of the commit history. > This helps speed up several operations involving commit walks. This > feature does not work well if those commits "change" using features like > commit grafts, replace objects, or shallow clones.

Re: RFC: New reference iteration paradigm

Jeff King writes: > On Thu, Mar 31, 2016 at 11:01:44AM -0700, Junio C Hamano wrote: >> Michael Haggerty writes: >> >>> the backend now has to implement >>> struct ref_iterator *ref_iterator_begin_fn(const char *submodule,

Re: [PATCH v3 02/20] commit-graph: fix GRAPH_MIN_SIZE

Derrick Stolee writes: > The GRAPH_MIN_SIZE macro should be the smallest size of a parsable > commit-graph file. However, the minimum number of chunks was wrong. > It is possible to write a commit-graph file with zero commits, and > that violates this macro's value. > >

Re: [PATCH v3 10/20] commit-graph: verify objects exist

Derrick Stolee writes: > In the 'verify' subcommand, load commits directly from the object > database to ensure they exist. Parse by skipping the commit-graph. All right, before we check that the commit data matches, we need to check that all the commits in cache (in the serialized commit

Re: [PATCH v3 11/20] commit-graph: verify root tree OIDs

Derrick Stolee writes: > The 'verify' subcommand must compare the commit content parsed from the > commit-graph and compare it against the content in the object database. You have "compare" twice in the above sentence. > Use lookup_commit() and parse_commit_in_graph_one() to parse the commits

Re: [PATCH v3 03/20] commit-graph: parse commit from chosen graph

Derrick Stolee writes: > Before verifying a commit-graph file against the object database, we > need to parse all commits from the given commit-graph file. Create > parse_commit_in_graph_one() to target a given struct commit_graph. If I understand it properly the problem

Re: [PATCH v3 12/20] commit-graph: verify parent list

Derrick Stolee writes: > The commit-graph file stores parents in a two-column portion of the > commit data chunk. If there is only one parent, then the second column > stores 0x to indicate no second parent. All right, it is certainly nice to have this information, but isn't it

Re: [PATCH v3 14/20] commit-graph: verify commit date

Derrick Stolee writes: Nice and simple. The only possible question may be the ordering of patches in the series, namely whether this change should be before or after test checking generation numbers. > Signed-off-by: Derrick Stolee > --- > commit-graph.c | 6 ++ >

Re: [PATCH v3 13/20] commit-graph: verify generation number

Derrick Stolee writes: > While iterating through the commit parents, perform the generation > number calculation and compare against the value stored in the > commit-graph. All right, that's good. What about commit-graph files that have GENERATION_NUMBER_ZERO for all its commits (because we

Re: [PATCH v3 15/20] commit-graph: test for corrupted octopus edge

Derrick Stolee writes: > The commit-graph file has an extra chunk to store the parent int-ids for > parents beyond the first parent for octopus merges. Our test repo has a > single octopus merge that we can manipulate to demonstrate the 'verify' > subcommand detects incorrect values in that

Re: [PATCH v3 19/20] gc: automatically write commit-graph files

Derrick Stolee writes: > The commit-graph file is a very helpful feature for speeding up git > operations. In order to make it more useful, write the commit-graph file > by default during standard garbage collection operations. I think you meant here "make it possible to write the commit-graph

Re: [PATCH v3 17/20] fsck: verify commit-graph

Derrick Stolee writes: > If core.commitGraph is true, verify the contents of the commit-graph > during 'git fsck' using the 'git commit-graph verify' subcommand. Run > this check on all alternates, as well. All right, so we have one config variable to control the use of serialized commit-graph

Re: [PATCH v3 18/20] commit-graph: add '--reachable' option

Derrick Stolee writes: > When writing commit-graph files, it can be convenient to ask for all > reachable commits (starting at the ref set) in the resulting file. This > is particularly helpful when writing to stdin is complicated, such as a > future integration with 'git gc' which will call >

Re: [PATCH v3 16/20] commit-graph: verify contents match checksum

Derrick Stolee writes: > The commit-graph file ends with a SHA1 hash of the previous contents. If > a commit-graph file has errors but the checksum hash is correct, then we > know that the problem is a bug in Git and not simply file corruption > after-the-fact. > > Compute the checksum right

Re: [PATCH v3 20/20] commit-graph: update design document

Derrick Stolee writes: > The commit-graph feature is now integrated with 'fsck' and 'gc', > so remove those items from the "Future Work" section of the > commit-graph design document. It is always nice to have such commit as a summary what was done in the series, and to have up to date roadmap.

Re: [RFC PATCH 4/6] commit-graph: avoid writing when repo is shallow

Derrick Stolee writes: > On 5/31/2018 10:30 PM, Junio C Hamano wrote: >> Derrick Stolee writes: >> >>> Shallow clones do not interact well with the commit-graph feature for >>> several reasons. Instead of doing the hard thing to fix those >>> interactions, instead prevent reading or writing a

Re: [PATCH v3 02/20] commit-graph: fix GRAPH_MIN_SIZE

"brian m. carlson" writes: > On Sat, May 26, 2018 at 08:46:09PM +0200, Jakub Narebski wrote: >> One issue: in the future when Git moves to NewHash, it could encounter >> then both commit-graph files using SHA-1 and using NewHash. What about >> GRPH_OID_LEN

Re: [PATCH v3 06/20] commit-graph: add 'verify' subcommand

Derrick Stolee writes: > On 5/27/2018 6:55 PM, Jakub Narebski wrote: >> Derrick Stolee writes: [...] >>> +static int verify_commit_graph_error; >>> + >>> +static void graph_report(const char *fmt, ...) >>> +{ >>>

Re: [PATCH v3 06/20] commit-graph: add 'verify' subcommand

Derrick Stolee writes: > If the commit-graph file becomes corrupt, we need a way to verify > that its contents match the object database. In the manner of > 'git fsck' we will implement a 'git commit-graph verify' subcommand > to report all issues with the file. > > Add

Re: [PATCH v3 08/20] commit-graph: verify required chunks are present

Derrick Stolee writes: > The commit-graph file requires the following three chunks: > > * OID Fanout > * OID Lookup > * Commit Data > > If any of these are missing, then the 'verify' subcommand should > report a failure. This includes the chunk IDs malformed or the > chunk count is truncated.

Re: [PATCH v3 07/20] commit-graph: verify catches corrupt signature

Derrick Stolee writes: > This is the first of several commits that add a test to check that > 'git commit-graph verify' catches corruption in the commit-graph > file. The first test checks that the command catches an error in > the file signature. This is a check that

Re: [PATCH v3 09/20] commit-graph: verify corrupt OID fanout and lookup

Derrick Stolee writes: > In the commit-graph file, the OID fanout chunk provides an index into > the OID lookup. The 'verify' subcommand should find incorrect values > in the fanout. > > Similarly, the 'verify' subcommand should find out-of-order values in > the OID lookup. O.K., the OID Lookup

Re: [PATCH v3 07/20] commit-graph: verify catches corrupt signature

Derrick Stolee writes: > On 5/28/2018 10:05 AM, Jakub Narebski wrote: >> Derrick Stolee writes: [...] >>> diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh >>> index 6ca451dfd2..bd64481c7a 100755 >>> --- a/t/t5318-commit-graph.sh >>>

Re: [PATCH v3 11/20] commit-graph: verify root tree OIDs

Derrick Stolee writes: > On 5/30/2018 6:24 PM, Jakub Narebski wrote: [...] >> NOTE: we will be checking Commit Data chunk; I think it would be good >> idea to verify that size of Commit Data chunk matches (N * (H + 16) bytes) >> that format gives us, so that we don't acc

Re: [PATCH v3 05/20] commit-graph: load a root tree from specific graph

Derrick Stolee writes: > When lazy-loading a tree for a commit, it will be important to select > the tree from a specific struct commit_graph. Create a new method that > specifies the commit-graph file and use that in > get_commit_tree_in_graph(). Is this for the same

Re: [PATCH v3 04/20] commit: force commit to parse from object database

Derrick Stolee writes: > In anticipation of verifying commit-graph file contents against the > object database, create parse_commit_internal() to allow side-stepping > the commit-graph file and parse directly from the object database. > > Due to the use of generation

Re: [PATCH v4 08/10] commit: add short-circuit to paint_down_to_common()

Derrick Stolee writes: > When running 'git branch --contains', the in_merge_bases_many() > method calls paint_down_to_common() to discover if a specific > commit is reachable from a set of branches. Commits with lower > generation number are not needed to correctly answer

Re: [PATCH v4 10/10] commit-graph.txt: update design document

Derrick Stolee <sto...@gmail.com> writes: > On 4/30/2018 7:32 PM, Jakub Narebski wrote: >> Derrick Stolee <dsto...@microsoft.com> writes: [...] >>> - After computing and storing generation numbers, we must make graph >>> walks aware of generation n

Re: [PATCH v4 09/10] merge: check config before loading commits

Derrick Stolee <sto...@gmail.com> writes: > On 4/30/2018 6:54 PM, Jakub Narebski wrote: >> Derrick Stolee <dsto...@microsoft.com> writes: >> >>> Now that we use generation numbers from the commit-graph, we must >>> ensure that all commits that

Re: [PATCH v4 08/10] commit: add short-circuit to paint_down_to_common()

Derrick Stolee <sto...@gmail.com> writes: > On 4/30/2018 6:19 PM, Jakub Narebski wrote: >> Derrick Stolee <dsto...@microsoft.com> writes: [...] >>> @@ -831,6 +834,13 @@ static struct commit_list *paint_down_to_common(struct >>> commit *one, int n, struc >

Re: [PATCH v4 03/10] commit-graph: compute generation numbers

Derrick Stolee <sto...@gmail.com> writes: > On 4/29/2018 5:08 AM, Jakub Narebski wrote: >> Derrick Stolee <dsto...@microsoft.com> writes: [...] >> It is a bit strange to me that the code uses get_be32 for reading, but >> htonl for writing. Is Git tested on non li

Re: [PATCH v4 04/10] commit: use generations in paint_down_to_common()

Junio C Hamano writes: > Derrick Stolee writes: > >> Define compare_commits_by_gen_then_commit_date(), which uses generation >> numbers as a primary comparison and commit date to break ties (or as a >> comparison when both commits do not have computed

Re: [PATCH v4 09/10] merge: check config before loading commits

Derrick Stolee writes: > Now that we use generation numbers from the commit-graph, we must > ensure that all commits that exist in the commit-graph are loaded > from that file instead of from the object database. Since the > commit-graph file is only checked if

Re: [PATCH v4 10/10] commit-graph.txt: update design document

Derrick Stolee writes: > We now calculate generation numbers in the commit-graph file and use > them in paint_down_to_common(). > > Expand the section on generation numbers to discuss how the three > special generation numbers GENERATION_NUMBER_INFINITY, _ZERO, and > _MAX

Re: [PATCH v4 04/10] commit: use generations in paint_down_to_common()

Derrick Stolee writes: > Define compare_commits_by_gen_then_commit_date(), which uses generation > numbers as a primary comparison and commit date to break ties (or as a > comparison when both commits do not have computed generation numbers). All right, this looks

Re: [PATCH v4 05/10] commit-graph: always load commit-graph information

Derrick Stolee writes: > Most code paths load commits using lookup_commit() and then > parse_commit(). And this automatically loads commit graph if needed, thanks to changes in parse_commit_gently(), which parse_commit() uses. > In some cases, including

Re: [PATCH v4 05/10] commit-graph: always load commit-graph information

[Forgot about one thing] Derrick Stolee writes: > Create new load_commit_graph_info() method to fill in the information > for a commit that exists only in the commit-graph file. The above sentence is a bit hard to parse because of ambiguity: is it "the information" that

Re: [PATCH v4 06/10] ref-filter: use generation number for --contains

Derrick Stolee writes: > A commit A can reach a commit B only if the generation number of A > is strictly larger than the generation number of B. This condition > allows significantly short-circuiting commit-graph walks. > > Use generation number for '--contains' type

Re: [PATCH v4 07/10] commit: use generation numbers for in_merge_bases()

Derrick Stolee writes: > The containment algorithm for 'git branch --contains' is different > from that for 'git tag --contains' in that it uses is_descendant_of() > instead of contains_tag_algo(). The expensive portion of the branch > algorithm is computing merge bases. >

Re: [PATCH v5 09/11] commit: use generation number in remove_redundant()

me is spent walking the history to find the > set of merge bases before the remove_redundant() call. The > starting commits are closer together in the second example, > therefore more time is spent in remove_redundant(). The relative > change in performance differs as expected. > > Rep

Re: [PATCH v4 01/10] ref-filter: fix outdated comment on in_commit_list

Derrick Stolee <dsto...@microsoft.com> writes: > The in_commit_list() method does not check the parents of > the candidate for containment in the list. Fix the comment > that incorrectly states that it does. > > Reported-by: Jakub Narebski <jna...@gmail.com> > Signe

Re: [PATCH v4 00/10] Compute and consume generation numbers

Derrick Stolee writes: > As promised, here is the diff from v3. What is this strange string "   " in place of tabs in the interdiff? " " here is Unicode Character 'NO-BREAK SPACE' (U+00A0). Though it doesn't matter for viewing, my newsreader (Gnus from GNU Emacs) thinks

Re: [PATCH v4 02/10] commit: add generation number to struct commmit

Derrick Stolee writes: > The generation number of a commit is defined recursively as follows: > > * If a commit A has no parents, then the generation number of A is one. > * If a commit A has parents, then the generation number of A is one > more than the maximum

Re: [PATCH v4 03/10] commit-graph: compute generation numbers

Derrick Stolee writes: > While preparing commits to be written into a commit-graph file, compute > the generation numbers using a depth-first strategy. Sidenote: for generation numbers it does not matter if we use depth-first or breadth-first strategy, but it is more

Re: [PATCH v5 00/11] Compute and consume generation numbers

Derrick Stolee writes: > Most of the changes from v4 are cosmetic, but there is one new commit: > > commit: use generation number in remove_redundant() > > Other changes are non-functional, but do clarify things. I wonder if out perf framework in t/perf could help

Re: [PATCH] gitweb: Measure offsets against UTF-8 flagged string

Junio C Hamano writes: > Shin Kojima writes: > >> Offset positions should not be counted by byte length, but by actual >> character length. >> ... >> # escape tabs (convert tabs to spaces) >> sub untabify { >> -my $line = shift; >> +my $line =

Re: [PATCH] DO-NOT-MERGE: write and read commit-graph always

Derrick Stolee writes: > This commit is not intended to be merged, but is only to create a test > environment to see what works with the commit-graph feature and what > does not. The tests that fail are primarily related to corrupting the > object store to remove a commit from visibility and

Re: [PATCH 8/8] commit-graph: close_commit_graph before shallow walk

"Derrick Stolee via GitGitGadget" writes: > From: Derrick Stolee > > Make close_commit_graph() work for arbitrary repositories. The first line (above) does not match the rest of the commit message. > Call close_commit_graph() when about to start a rev-list walk that > includes shallow

Re: [PATCH 0/8] Clarify commit-graph and grafts/replace/shallow incompatibilities

"Derrick Stolee via GitGitGadget" writes: Sidenote: the GitGitGadget doesn't fold/wrap lines properly in the cover-letter. Not that it is much of a problem. > One unresolved issue with the commit-graph feature is that it can > cause issues when combined with replace objects, commit grafts, or

Re: [PATCH 3/8] commit-graph: update design document

"Derrick Stolee via GitGitGadget" writes: > From: Derrick Stolee > > As it exists right now, the commit-graph feature may provide > inconsistent results when combined with commit grafts, replace objects, > and shallow clones. Update the design document to discuss why these > interactions are

Re: [PATCH 4/8] test-repository: properly init repo

"Derrick Stolee via GitGitGadget" writes: > From: Derrick Stolee > > Signed-off-by: Derrick Stolee > --- > t/helper/test-repository.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/t/helper/test-repository.c b/t/helper/test-repository.c > index

Re: [PATCH 5/8] commit-graph: not compatible with replace objects

"Derrick Stolee via GitGitGadget" writes: > From: Derrick Stolee > > Create new method commit_graph_compatible(r) to check if a given > repository r is compatible with the commit-graph feature. Fill the > method with a check to see if replace-objects exist. All right, looks sensible. Did you

Re: [PATCH 6/8] commit-graph: not compatible with grafts

"Derrick Stolee via GitGitGadget" writes: > From: Derrick Stolee > > Augment commit_graph_compatible(r) to return false when the given > repository r has commit grafts or is a shallow clone. Test that in these > situations we ignore existing commit-graph files and we do not write new >

Re: [PATCH 7/8] commit-graph: not compatible with uninitialized repo

"Derrick Stolee via GitGitGadget" writes: [I hope that the rest of replies would make it all right through GitGitGadget] > From: Derrick Stolee > > Signed-off-by: Derrick Stolee > --- > commit-graph.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/commit-graph.c b/commit-graph.c

Re: [PATCH] DO-NOT-MERGE: write and read commit-graph always

Stefan Beller writes: >> I wonder though if all those changes to the testsuite shouldn't be >> merged. > > I think Stolee doesn't want this to be merged after rereading > subject and the commit message. Yes, I understand that, and for the most part I agree with it. This commit main purpose is

Re: What's cooking in git.git (Aug 2018, #01; Thu, 2)

Junio C Hamano writes: > * ds/commit-graph-with-grafts (2018-07-19) 8 commits > (merged to 'next' on 2018-08-02 at 0ee624e329) > + commit-graph: close_commit_graph before shallow walk > + commit-graph: not compatible with uninitialized repo > + commit-graph: not compatible with grafts > +

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

Derrick Stolee writes: [...] > On the Linux repository, performance tests were run for the following > command: > > git log --graph --oneline -1000 > > Before: 0.92s > After: 0.66s > Rel %: -28.3% > > Adding '-- kernel/' to the command requires loading the

Re: [PATCH v7 09/14] commit-graph: add core.commitGraph setting

Derrick Stolee writes: > From: Derrick Stolee > > The commit graph feature is controlled by the new core.commitGraph config > setting. This defaults to 0, so the feature is opt-in. Nice. That's how bitmaps feature was introduced, I think. I guess that

Re: [PATCH v7 08/14] commit-graph: implement git commit-graph read

Derrick Stolee writes: [...] > EXAMPLES > > @@ -45,6 +51,12 @@ EXAMPLES > $ git commit-graph write > > > +* Read basic information from the commit-graph file. > ++ >

Re: Is offloading to GPU a worthwhile feature?

Hello, Konstantin Ryabitsev writes: > This is an entirely idle pondering kind of question, but I wanted to > ask. I recently discovered that some edge providers are starting to > offer systems with GPU cards in them -- primarily for clients that need > to provide

Re: [PATCH v7 04/14] graph: add commit graph design document

Derrick Stolee writes: > From: Derrick Stolee > > Add Documentation/technical/commit-graph.txt with details of the planned > commit graph feature, including future plans. That's in my opinion a very good idea. It would help anyone trying to add to and

Re: [PATCH v7 13/14] commit-graph: build graph from starting commits

Derrick Stolee writes: > @@ -96,10 +101,12 @@ static int graph_write(int argc, const char **argv) >builtin_commit_graph_write_options, >builtin_commit_graph_write_usage, 0); > > + if (opts.stdin_packs &&

Re: [PATCH v7 07/14] commit-graph: implement git-commit-graph write

Derrick Stolee writes: > +# Current graph structure: > +# > +# __M3___ > +# / | \ > +# 3 M1 5 M2 7 > +# |/ \|/ \| > +# 246 > +# |___// > +# 1 Good, so we are testing EDGE chunk, because the commit graph has octopus merge in it (with more than two parents).

Re: Is offloading to GPU a worthwhile feature?

Konstantin Ryabitsev <konstan...@linuxfoundation.org> writes: > On 04/08/18 09:59, Jakub Narebski wrote: >>> This is an entirely idle pondering kind of question, but I wanted to >>> ask. I recently discovered that some edge providers are starting to >>>

Re: [PATCH v8 03/14] commit-graph: add format document

Derrick Stolee writes: > +CHUNK DATA: > + > + OID Fanout (ID: {'O', 'I', 'D', 'F'}) (256 * 4 bytes) > + The ith entry, F[i], stores the number of OIDs with first > + byte at most i. Thus F[255] stores the total > + number of commits (N). > + > + OID Lookup (ID:

Re: [PATCH 0/6] Compute and consume generation numbers

Derrick Stolee <sto...@gmail.com> writes: > On 4/7/2018 12:55 PM, Jakub Narebski wrote: >> Currently I am at the stage of reproducing results in FELINE paper: >> "Reachability Queries in Very Large Graphs: A Fast Refined Online Search >> Approach" by Renê

Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)

Junio C Hamano writes: > * ab/nuke-emacs-contrib (2018-03-13) 1 commit > (merged to 'next' on 2018-03-15 at 13eb4e2d8b) > + git{,-blame}.el: remove old bitrotting Emacs code > > The scripts in contrib/emacs/ have outlived their usefulness and > have been removed. > >

Re: [PATCH v2 0/4] Lazy-load trees when reading commit-graph

Derrick Stolee <sto...@gmail.com> writes: > On 4/7/2018 2:40 PM, Jakub Narebski wrote: >> Derrick Stolee <dsto...@microsoft.com> writes: >> >> [...] >>> On the Linux repository, performance tests were run for the following >>> co

Re: [PATCH] completion: reduce overhead of clearing cached --options

SZEDER Gábor writes: > To get the names of all '$__git_builtin_*' variables caching --options > of builtin commands in order to unset them, 8b0eaa41f2 (completion: > clear cached --options when sourcing the completion script, > 2018-03-22) runs a 'set |sed s///' pipeline.

Re: File versioning based on shallow Git repositories?

Hello Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > On Fri, 13 Apr 2018, Jakub Narebski wrote: >> Hallvard Breien Furuseth <h.b.furus...@usit.uio.no> writes: >> >>> Also maybe it'll be worthwhile to generate .git/info/grafts in a loc

Re: [PATCH v8 03/14] commit-graph: add format document

Derrick Stolee <sto...@gmail.com> writes: > On 4/11/2018 4:58 PM, Jakub Narebski wrote: >> Derrick Stolee <sto...@gmail.com> writes: >> >>> +CHUNK DATA: >>> + >>> + OID Fanout (ID: {'O', 'I', 'D', 'F'}) (256 * 4 bytes) >>> +

Re: [PATCH] completion: reduce overhead of clearing cached --options

SZEDER Gábor <szeder@gmail.com> writes: > On Fri, Apr 13, 2018 at 11:44 PM, Jakub Narebski <jna...@gmail.com> wrote: >> SZEDER Gábor <szeder@gmail.com> writes: >>> >>> In Bash we can do better: run the 'compgen -v __gitcomp_builtin_' >&g

Re: [PATCH 0/6] Compute and consume generation numbers

Derrick Stolee writes: > On 4/3/2018 2:03 PM, Brandon Williams wrote: >> On 04/03, Derrick Stolee wrote: >>> This is the first of several "small" patches that follow the serialized >>> Git commit graph patch (ds/commit-graph). >>> >>> As described in

Re: [PATCH 0/6] Compute and consume generation numbers

Hello, Derrick Stolee writes: > This is the first of several "small" patches that follow the serialized > Git commit graph patch (ds/commit-graph). > > As described in Documentation/technical/commit-graph.txt, the generation > number of a commit is one more than the

Re: Git Merge contributor summit notes

Brandon Williams writes: > On 03/26, Jeff Hostetler wrote: [...] >> All of these cases could be eliminated if the type/size were available >> in the OID. >> >> Just a thought. While we are converting to a new hash it seems like >> this would be a good time to at least

  1   2   >