From: Jeff King <peff@peff.net>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org, gitster@pobox.com, peartben@gmail.com,
benpeart@microsoft.com
Subject: Re: [PATCH 2/3] revision: exclude trees/blobs given commit
Date: Tue, 28 Feb 2017 17:12:37 -0500 [thread overview]
Message-ID: <20170228221236.selqkf5wme3fvued@sigill.intra.peff.net> (raw)
In-Reply-To: <7082d91f30663b2e6d7fb1795c5ea37d3fe3446c.1487984670.git.jonathantanmy@google.com>
On Fri, Feb 24, 2017 at 05:18:37PM -0800, Jonathan Tan wrote:
> When the --objects argument is given to rev-list, an argument of the
> form "^$tree" can be given to exclude all blobs and trees reachable from
> that tree, but an argument of the form "^$commit" only excludes that
> commit, not any blob or tree reachable from it. Make "^$commit" behave
> consistent to "^$tree".
Like Junio, I suspect this is going to be quite expensive. This is
similar to the "--objects-edge" and "--objects-edge-aggressive" options,
which we had to pull back on the use of because of their expensiveness.
(And as an aside, wouldn't those options be the right place for what
you're doing?).
I also think that the mechanism here is not 100% accurate. The commit
traversal will stop once it has painted down, so you're effectively
exploring the trees of the merge bases. But older history could mention
an object that has resurfaced again (e.g., due to a cherry-pick).
Getting the 100% accurate answer is _really_ expensive, though with
reachability bitmaps it's not too bad. I just wonder if that's a better
approach to be taking.
-Peff
next prev parent reply other threads:[~2017-02-28 22:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-25 1:18 [PATCH 0/3] Test fetch-pack's ability to fetch arbitrary blobs Jonathan Tan
2017-02-25 1:18 ` [PATCH 1/3] revision: unify {tree,blob}_objects in rev_info Jonathan Tan
2017-02-28 21:42 ` Junio C Hamano
2017-02-28 21:59 ` Jeff King
2017-03-02 18:36 ` Junio C Hamano
2017-02-28 22:06 ` Jeff King
2017-02-25 1:18 ` [PATCH 2/3] revision: exclude trees/blobs given commit Jonathan Tan
2017-02-28 21:44 ` Junio C Hamano
2017-02-28 22:12 ` Jeff King [this message]
2017-03-02 19:50 ` [PATCH] t/perf: export variable used in other blocks Jonathan Tan
2017-03-03 6:45 ` Jeff King
2017-03-03 7:14 ` [PATCH] t/perf: use $MODERN_GIT for all repo-copying steps Jeff King
2017-03-03 7:36 ` [PATCH] t/perf: add fallback for pre-bin-wrappers versions of git Jeff King
2017-03-03 18:51 ` [PATCH] t/perf: export variable used in other blocks Junio C Hamano
2017-03-03 22:31 ` Jeff King
2017-02-28 23:12 ` [PATCH 2/3] revision: exclude trees/blobs given commit Junio C Hamano
2017-02-25 1:18 ` [PATCH 3/3] upload-pack: compute blob reachability correctly Jonathan Tan
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170228221236.selqkf5wme3fvued@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=benpeart@microsoft.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=peartben@gmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.