On Fri, Jan 25, 2019 at 11:14:14PM +0100, SZEDER Gábor wrote:
> On Fri, Jan 25, 2019 at 11:56:38AM -0800, Stefan Beller wrote:
> > > Have fun! :)
> >
> > $ git gc
> > ...
> > Computing commit graph generation numbers: 100% (164264/164264), done.
> > $ ./git version
> > git version 2.20.1.775.g2313
On Fri, Jan 25, 2019 at 11:56:38AM -0800, Stefan Beller wrote:
> > Have fun! :)
>
> $ git gc
> ...
> Computing commit graph generation numbers: 100% (164264/164264), done.
> $ ./git version
> git version 2.20.1.775.g2313a6b87fe.dirty
> # pu + one commit addressing
> #
> https://public-inbox.org/g
> > Have fun! :)
>
> $ git gc
> ...
> Computing commit graph generation numbers: 100% (164264/164264), done.
> $ ./git version
> git version 2.20.1.775.g2313a6b87fe.dirty
> # pu + one commit addressing
> #
> https://public-inbox.org/git/cagz79kaug3ntrpri5mlk6ag87idb_ltq_keilwz2hgz+-vs...@mail.gma
> Have fun! :)
$ git gc
...
Computing commit graph generation numbers: 100% (164264/164264), done.
$ ./git version
git version 2.20.1.775.g2313a6b87fe.dirty
# pu + one commit addressing
#
https://public-inbox.org/git/cagz79kaug3ntrpri5mlk6ag87idb_ltq_keilwz2hgz+-vs...@mail.gmail.com/
$ ./git -c
On Tue, Dec 04, 2018 at 02:42:38PM -0800, Jonathan Tan wrote:
> When fetching into a repository, a connectivity check is first made by
> check_exist_and_connected() in builtin/fetch.c that runs:
>
> git rev-list --objects --stdin --not --all --quiet <(list of objects)
>
> If the client reposito
On 12/6/2018 6:36 PM, Jonathan Tan wrote:
AFAICT oid_object_info doesn't take advantage of the commit graph,
but just looks up the object header, which is still less than completely
parsing it. Then lookup_commit is overly strict, as it may return
NULL as when there still is a type mismatch (I do
On Thu, Dec 06, 2018 at 03:54:46PM -0800, Jonathan Tan wrote:
> This makes sense - I thought I shouldn't mention the commit graph in the
> code since it seems like a layering violation, but I felt the need to
> mention commit graph in a comment, so maybe the need to mention commit
> graph in the c
Also CC-ing Stolee since I mention multi-pack indices at the end.
> This seems like a reasonable thing to do, but I have sort of a
> meta-comment. In several places we've started doing this kind of "if
> it's this type of object, do X, otherwise do Y" optimization (e.g.,
> handling large blobs for
> > This is on sb/more-repo-in-api because I'm using the repo_parse_commit()
> > function.
>
> This is a mere nicety, not strictly required.
> Before we had parse_commit(struct commit *) which would accomplish the
> same, (and we'd still have that afterwards as a #define falling back onto
> the_re
Jonathan Tan writes:
> Looking at the bigger picture, the speed of the connectivity check
> during a fetch might be further improved by passing only the negotiation
> tips (obtained through --negotiation-tip) instead of "--all". This patch
> just handles the low-hanging fruit first.
That sounds
On Tue, Dec 04, 2018 at 02:42:38PM -0800, Jonathan Tan wrote:
> diff --git a/revision.c b/revision.c
> index b5108b75ab..e7da2c57ab 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -212,7 +212,20 @@ static struct object *get_reference(struct rev_info
> *revs, const char *name,
> {
> struc
On Tue, Dec 4, 2018 at 2:42 PM Jonathan Tan wrote:
>
> When fetching into a repository, a connectivity check is first made by
> check_exist_and_connected() in builtin/fetch.c that runs:
>
> git rev-list --objects --stdin --not --all --quiet <(list of objects)
>
> If the client repository has man
When fetching into a repository, a connectivity check is first made by
check_exist_and_connected() in builtin/fetch.c that runs:
git rev-list --objects --stdin --not --all --quiet <(list of objects)
If the client repository has many refs, this command can be slow,
regardless of the nature of th
13 matches
Mail list logo
