From: Jeff King <peff@peff.net>
To: Paul van Loon <nospam@cheerful.com>
Cc: Jonathan Tan <jonathantanmy@google.com>, git@vger.kernel.org
Subject: Re: [BUG/FEATURE] Git pushing and fetching many more objects than strictly required
Date: Fri, 8 Nov 2019 16:21:56 -0500 [thread overview]
Message-ID: <20191108212156.GA15365@sigill.intra.peff.net> (raw)
In-Reply-To: <e537d298-6431-c36a-2fc3-e41baa10d0a3@cheerful.com>
On Fri, Nov 08, 2019 at 09:54:02PM +0100, Paul van Loon wrote:
> >> $ git push -v origin 'refs/replace/*:refs/replace/*'
> >> Pushing to XXXX
> >> Enumerating objects: 2681, done.
> >> Counting objects: 100% (2681/2681), done.
> >> Delta compression using up to 8 threads
> >> Compressing objects: 100% (1965/1965), done.
> >> Writing objects: 100% (2582/2582), 1.96 MiB | 1024 bytes/s, done.
> >> Total 2582 (delta 95), reused 1446 (delta 58)
> >> remote: Resolving deltas: 100% (95/95), completed with 33 local objects.
> >> To XXXX
> >> * [new branch] refs/replace/XXXX -> refs/replace/XXXX
> >
> > Could you verify that refs/replace/XXXX (or one of its close ancestors)
> > was fetched by the "git fetch --all" command? "--all" fetches all
> > remotes, not all refs.
>
> No, it was not fetched. HOWEVER, the ONLY thing the replace commit (1 single object) does is point to an existing parent object. No other new objects are referenced.
> Those 'ancestor' objects were all fetched.
Was it a parent object at the tip of a ref?
The push protocol, unlike the fetch protocol, doesn't expend any effort
to negotiate to find a common base. It just feeds the ref tips of the
receiver to pack-objects (which then does traverse down to a merge base,
but it can't always do so if the sender doesn't have all of the
objects).
It's hard to say more without having a reproducible case to look at.
Some possible things to poke at:
- record the stdin from the local push to the local pack-objects,
which shows which objects we're planning to send and which we're
claiming the other side has. That would help determine if the push
isn't feeding enough information to pack-objects, or if pack-objects
isn't trying hard enough to find the minimal set of objects
There's not really an easy way to do this, but something like strace
might help.
- try building reachability bitmaps (e.g., "git repack -adb") in the
local clone. When those are present, pack-objects will compute the
object set more thoroughly (because it can do so efficiently).
I don't _think_ the fact that it's in refs/replace should matter to push
(in terms of what it feeds to pack-objects). But obviously another thing
to try is whether pushing to or from a different ref has any impact.
-Peff
next prev parent reply other threads:[~2019-11-08 21:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-08 14:06 [BUG/FEATURE] Git pushing and fetching many more objects than strictly required Paul van Loon
2019-11-08 18:47 ` Jonathan Tan
2019-11-08 20:54 ` Paul van Loon
2019-11-08 21:21 ` Jeff King [this message]
2019-11-12 13:39 ` Paul van Loon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191108212156.GA15365@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=jonathantanmy@google.com \
--cc=nospam@cheerful.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).