First, the commit message could probably be reordered to start with the
main point (reusing of packfiles at object granularity instead of
allowing reuse of only one contiguous region). To specific points:
> The dynamic array of `struct reused_chunk` is useful
> because we need to know not just the
> From: Jeff King
>
> In a following commit we will need to allocate a variable
> number of bitmap words, instead of always 32, so let's add
> bitmap_word_alloc() for this purpose.
>
> We will also always access at least one word for each bitmap,
> so we want to make sure that at least one is al
> From: Heba Waly
>
> This commit is copying and summarizing the documentation from
> documentation/technical/api-config.txt to comments in config.h
Thanks for this commit!
As for your commit message, as far as I know, the idea is to move the
documentation, not to copy it. Also, write this in i
that this patch is a net improvement.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 336 ---
1 file changed, 190 insertions(+), 146 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 31607a77fc..072592a35d 100644
--- a/bu
possible moment. This allowed the members of struct base_data to be
populated in any order, superficially useful when we have the object
contents before the struct object_entry. But this makes reasoning about
the state of struct base_data more complicated, hence this patch.
Signed-off-by: Jonathan Tan
A subsequent commit will make the quantum of work smaller, necessitating
more locking. This commit allows resolve_delta() to be called outside
the lock.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin/index
find_{ref,ofs}_delta_{,children} take an enum object_type parameter, but
the object type is already present in the name of the function. Remove
that parameter from these functions.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 26 --
1 file changed, 12
;
pointer is redundant even now, remove it so that the aforementioned
subsequent patch will be clearer. In the meantime, reclaim memory in the
reverse order of the "base" pointers.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 41 ++---
1 f
Clarify that core.deltaBaseCacheLimit is per-thread, as can be seen from
the fact that cache usage (base_cache_used in struct thread_local in
builtin/index-pack.c) is tracked individually for each thread and
compared against delta_base_cache_limit.
Signed-off-by: Jonathan Tan
---
Documentation
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 60a5591039..df6b3b8cf6 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1210,15 +1210,7 @@ static
ve
> puzzled all that out, it would be nice to make the argument in the
> commit message.
I've added an explanation in the commit message.
Jonathan Tan (7):
Documentation: deltaBaseCacheLimit is per-thread
index-pack: unify threaded and unthreaded code
index-pack: remove redundant parameter
> There was some discussion recently about converting these related
> #defines to enums [0]. We might consider doing that here.
>
> If you read through that entire thread, you'd see that there were some
> disagreements about whether using enums for sets of bits is a good idea
> ([1] and [2]), b
TTP protocol v2 (fetch_refs_via_pack() in transport.c sets
lock_pack) and with HTTP protocol v0/v1 (fetch_git() in remote-curl.c
passes "--lock-pack" to "fetch-pack").
Signed-off-by: Jonathan Tan
---
Changes from v1:
- commit message explains scope of change ("it knows the name of t
Thanks for your comments. Rearranging them:
> This makes me wonder why we don't also change index-pack to write a
> similar message to the .promisor. I guess there's potentially too much
> information to shove all the refs on the command-line?
index-pack already is capable of writing messages to
> > Well, I agree that it could be better, but with the C language as we
> > have it now, I still slightly prefer an enum to a list of #define. Both
> > ways, we still have to manually enter values for each flag, but with
> > enum, we get better debugger display (at least in gdb) and in the
> > fun
> Jonathan Tan writes:
>
> >> > Also, I have a slight preference for putting "= 02" on the BLAME_COPY
> >> > line but that is not necessary.
> >>
> >> That is absolutely necessary; it is not like "we do not care what
> >
> As a general rule (and why I'm raising this issue in reply to Jonathan's
> patch), I think most or all sites that want OBJECT_INFO_QUICK will want
> SKIP_FETCH_OBJECT as well, and vice versa. The reasoning is generally
> the same:
>
> - it's OK to racily have a false negative (we'll still be c
> > This makes sense - offsets may be different when we omit objects from
> > the packfile. I think this can be computed by calculating the number of
> > zero bits between the current object's index and the nth object prior
> > (where n is the offset) in the bitmap resulting from
> > reuse_partial_
> > Any reason why the names are renamed to omit "PICKAXE_"? In particular,
> > these names are still global, so it is good to retain the extra context.
> >
> > (This doesn't mean that you are wrong to remove them - I just gave my
> > opinion, and a reason for my opinion. If you had a reason to re
> Jonathan Tan writes:
>
> >> - if ((opt & PICKAXE_BLAME_COPY_HARDEST)
> >> - || ((opt & PICKAXE_BLAME_COPY_HARDER)
> >> + if ((opt & BLAME_COPY_HARDEST)
> >> + || ((opt & BLAME_COPY_HARDER)
> >
> > Any reason
I'm going to start with pack-bitmap.h, then builtin/pack-objects.c.
> int reuse_partial_packfile_from_bitmap(struct bitmap_index *,
> struct packed_git **packfile,
> -uint32_t *entries, off_t *up_to);
> +
> As we now allocate 2 more words than necessary for each
> bitmap to serve as marks telling us that we can stop
> iterating over the words, we don't need to rely on
> bitmap_git->reuse_objects to stop iterating over the words.
As Peff states [1], this justification is probably incorrect as well.
> From: Jeff King
>
> In a following patch we will allocate a variable number
> of words in some bitmaps. When iterating over the words we
> will need a mark to tell us when to stop iterating. Let's
> always allocate 2 more words, that will always contain 0,
> as that mark.
[snip]
> if (b
> On 10/9/2019 7:44 PM, Jonathan Tan wrote:
> > Instead, recompute ancestry if we ever need to reclaim memory.
>
> I find this message lacking in important details:
>
> 1. Where do we recompute ancestry?
> 2. What are the performance implications of this change?
> 3. W
> Hello Jonathan!
> My name is Wambui and I'm one of the applicants in the current round of
> Outreachy applications. I wanted to write an initial email to introduce
> myself since I'm interested in working on your mentored projects!
>
> I have been going through the mailing list threads about Out
> Convert pickaxe_blame preprocessor constants in blame.h to an enum.
> Also replace previous instances of the constants with the new enum values.
First of all, thanks for your initiative in finding a microproject and
making a patch for it!
About your commit message title, I know that 50 characte
Whenever we make a struct base_data, immediately calculate its delta
children. This eliminates confusion as to when the
{ref,ofs}_{first,last} fields are initialized.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 125 +--
1 file changed, 61
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 1a2600d4b3..99f6e2957f 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -614,7
Instead, recompute ancestry if we ever need to reclaim memory.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 99f6e2957f
A subsequent commit will make the quantum of work smaller, necessitating
more locking. This commit allows resolve_delta() to be called outside
the lock.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin/index
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index a23454da6e..1a2600d4b3 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1210,15 +1210,7 @@ static
ens during repack.
[1]
https://public-inbox.org/git/20190926003300.195781-1-jonathanta...@google.com/
[2] https://public-inbox.org/git/20190704100530.smn4rpiekwtfy...@glandium.org/
Jonathan Tan (6):
index-pack: unify threaded and unthreaded code
index-pack: remove redundant parameter
index-
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 267 ---
1 file changed, 127 insertions(+), 140 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 3908cd3115..f6318037ca 100644
--- a/builtin/index-pack.c
+++ b/builtin/index
o not help at all in the typical case where the client is
up-to-date with the upstream of the branch being pushed.
Ensure that these lazy fetches do not occur.
Signed-off-by: Jonathan Tan
---
> For example, would this change mean that the resulting pack may
> include stuff that are re
> Changes since V1:
> * Use the repository struct argument in transport_push(), rather than
> the global the_repository.
Thanks, the patches now look good to me. I verified that the repository
argument to the trace functions just cause a different repo ID to be
printed, which is what we want (e.
> We'd like to collect better statistics about where the time is spent in
> fetches and pushes so that we can hopefully identify some areas for
> future optimization. So let's add some trace2 regions around some of the
> fetch/push phases so we can break down their timing.
Thanks.
Patch 1 looks g
ch. Ensure that this lazy fetch does not occur.
Signed-off-by: Jonathan Tan
---
send-pack.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/send-pack.c b/send-pack.c
index 6dc16c3211..34c77cbb1a 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -40,7 +40,8 @@ int option_parse_p
When running "git fetch" in a partial clone with no blobs, for example,
by:
git clone --filter=blob:none --no-checkout \
https://kernel.googlesource.com/pub/scm/git/git
git -C git fetch
"git fetch" will fail to load the config blob object, printing "unable
to load config blob object".
Th
> For those who want to know, this question was motivated by a big delta
> tree occurring in [1].
Forgot to mention: this is not an issue of the server not repacking with
a chain length limit. The tree in question is indeed not tall, but it is
very wide.
Does anyone have ideas or plans for this? I know that (at least) "grep"
and "index-pack" have their own implementations, and it would be great
to just have one that all code can use.
For those who want to know, this question was motivated by a big delta
tree occurring in [1]. index-pack does paral
s stated better what I would have
said, so to this patch:
Acked-by: Jonathan Tan
> On Mon, Sep 23, 2019 at 01:38:54PM -0700, Jonathan Tan wrote:
>
> > I didn't have any concrete ideas so I didn't include those, but some
> > unrefined ideas:
>
> One risk to a mentoring project like this is that the intern does a good
> job of steps 1-5, a
> I approved this. I did leave some comments elsewhere in the thread, but
> I think we can continue to iterate on the idea.
Thanks.
> > There was a "How can applicants make a contribution to your project?"
> > question and a few questions about communication channels. I answered
> > them as best
> I think this is an OK level of detail. I'm not sure quite sure about the
> goal of the project, though. In particular:
>
> - I'm not clear what we'd hope to gain. I.e., what richer information
> would we want to pass back and forth between index-pack and the
> other processes? It might
> No need for user-facing benefits. Refactoring or improving the code in
> other useful ways are very good subjects (as I already said in my
> reply to Emily and Dscho).
Thanks!
> I think this is really great, both the idea and the description! No
> need for more details.
Thanks! I've just submi
> Jonathan Tan writes:
>
> >> OK. We notice that we need to newly create foo/bar but we
> >> incorrectly find that there is "foo/bar" already because of the
> >> careless use of bare lstat(2) makes "bar" visible as if it were also
> >&
> OK. We notice that we need to newly create foo/bar but we
> incorrectly find that there is "foo/bar" already because of the
> careless use of bare lstat(2) makes "bar" visible as if it were also
> "foo/bar". I wonder if the current code would be confused the same
> way if the side branch added
> Prospective mentors need to sign up on that site, and should propose a
> project they'd be willing to mentor.
[snip]
> I'm happy to discuss possible projects if anybody has an idea but isn't
> sure how to develop it into a proposal.
I'm new to Outreachy and programs like this, so does anyone h
> * jt/cache-tree-avoid-lazy-fetch-during-merge (2019-09-09) 1 commit
> - cache-tree: do not lazy-fetch tentative tree
>
> The cache-tree code has been taught to be less aggressive in
> attempting to see if a tree object it computed already exists in
> the repository.
>
> Waiting for a respo
Helped-by: Elijah Newren
Signed-off-by: Jonathan Tan
---
Changes from v1:
- Used has_symlink_leading_path(). This drastically shortens the diff.
- Updated commit message following suggestions from Junio, Szeder Gábor,
and Elijah Newren.
- Updated test to add prereq and verification that the workin
> Yeah, I recall having to add has_symlink_leading_path() long time
> ago in different codepaths (including "apply"). It is not surprising
> to see a similar glitch remaining in merge-recursive (it's a tricky
> issue, and it's a tricky code).
Thanks for the pointer to has_symlink_leading_path() -
> Jonathan Tan writes:
>
> > When the working tree has:
> > - foo (symlink)
> > - foo/bar (directory)
>
> Whoa, wait. I assume, since this is about merge, the assumption is
> that the working tree is clean with respect to the index, so 'foo'
>
one", and will handle it as "Add/delete" or
"Modify/delete" appropriately (including reinstatement of the previously
unlinked symlink with a new unique filename if necessary, again, just
like if "foo" were a regular file instead).
Helped-by: Elijah Newren
S
This was raised by a coworker at $DAYJOB. I run the following script:
$GIT init test && cd test
ln -s . foo
mkdir bar && touch bar/file
$GIT add foo bar/file
$GIT commit -m "foo symlink"
$GIT checkout -b branch1
$GIT commit --allow-empty -m "empty commit"
$GIT checkout master
> Do we have interested mentors for the next round of Outreachy?
>
> The deadline for Git to apply to the program is September 5th. The
> deadline for mentors to have submitted project descriptions is September
> 24th. Intern applications would start on October 1st.
>
> If there are mentors who w
> Sidenote, just curious: did you originally intend to add this test
> before the test script sources 'lib-httpd.sh', or you were about to
> append it at the end as usual, but then noticed the warning comment
> telling you not to do so?
Honestly, I don't remember. I do try to put tests near simila
> Junio C Hamano writes:
>
> > Isn't that what is going on? I thought I dug up the original that
> > introduced the has_object_file() call to this codepath to make sure
> > we understand why we make the check (and I expected the person who
> > is proposing this change to do the same and record t
is both unnecessary (because we have the tree in the struct
strbuf) and likely to fail (because the remote probably doesn't have
this tree).
Do not lazy fetch in this situation.
Signed-off-by: Jonathan Tan
---
As requested in What's Cooking [1], here's a patch with an updated
> I'm not really opposed to what you're doing here, but I did recently
> think of another possible use for .promisor files. So it seems like a
> good time to bring it up, since presumably we'd have to choose one or
> the other.
Thanks for bringing it up - yes, we should discuss this.
> I noticed
> On 9/3/2019 3:42 PM, Jonathan Tan wrote:
> > When cherry-picking (for example), new trees may be constructed. During
> > this process, Git checks whether these trees exist. However, in a
> > partial clone, this causes a lazy fetch to occur, which is both
> > unnecessa
) and likely to fail (because the remote
probably doesn't have this tree).
Do not lazy fetch in this situation.
Signed-off-by: Jonathan Tan
---
Another partial clone bug.
This raises the issue that failed fetches are currently fatal - if they
weren't fatal, this cherry-pick would h
> Jonathan Tan writes:
>
> > As written in the NEEDSWORK comment, repack does not preserve the
> > contents of .promisor files, but I thought I'd send this out anyway as
> > this change is already useful for users who don't run repack much.
>
> What
hashes
against what the promisor remote reports now.
Signed-off-by: Jonathan Tan
---
As written in the NEEDSWORK comment, repack does not preserve the
contents of .promisor files, but I thought I'd send this out anyway as
this change is already useful for users who don't run r
> This probably is totally off-tangent, but do any of these "let's
> advertise fewer" changes at the protocol level have to take into
> account the use of --prune option on the client side?
I don't think so. According to what I understand from the documentation,
the prune option prunes based on th
> I wondered what would happen when it does not succeed. It looks like the
> whole diff process just dies.
>
> The batch fetch is purely an optimization, because we'd eventually fetch
> the individual objects on demand. If the batch one fails, should we
> continue with the operation? That leaves a
The only transport that does not allow fetch() to be called before
get_refs_list() is the bundle transport. Clean up the code by teaching
the bundle transport the ability to do this, and removing support for
transports that don't support this order of invocation.
Signed-off-by: Jonatha
re of the value of the test in patch 2, but that test does
fail if I don't update fetch_refs_from_bundle() to first call
get_refs_from_bundle() if it hasn't already been called.
Jonathan Tan (2):
transport-helper: skip ls-refs if unnecessary
transport: teach all vtables to allow fetch
if needed). If not, the remote helper interface will invoke
get_refs_list() if it hasn't been invoked yet, preserving existing
behavior.
Signed-off-by: Jonathan Tan
---
t/t5702-protocol-v2.sh | 13 +
transport-helper.c | 39 +--
2 file
> Jonathan Tan writes:
>
> > In 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08),
> > diff was taught to batch the fetching of missing objects when operating
> > on a partial clone, but was not taught to refrain from fetching
> > GITLINK
In 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08),
diff was taught to batch the fetching of missing objects when operating
on a partial clone, but was not taught to refrain from fetching
GITLINKs. Teach diff to check if an object is a GITLINK before including
it in the set to be f
Thanks - I think this is a useful guide to what can be a complicated
topic. It looks good overall; I just have some minor comments below.
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 76f2ecfc1b..91e5da67c4 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefi
> When cloning a repo with a --filter and with --recurse-submodules
> enabled, the partial clone filter only applies to the top-level repo.
> This can lead to unexpected bandwidth and disk usage for projects which
> include large submodules.
>
> Fix this by plumbing the --filter argument from git-
> This applies suggestions made by Jonathan Tan, as well as fixes a
> Coccinelle-breaking error in strbuf usage, and makes an additional string
> localizable.
>
> Thanks,
>
> Matthew DeVore (10):
> list-objects-filter: encapsulate filter components
> list-objec
Junio, what do you think of this small patch that just updates a test:
https://public-inbox.org/git/20190605192624.129677-1-jonathanta...@google.com/
For what it's worth, Stolee and Peff have replied and both of them seem
to be OK with it.
> This function always returns 0, so make it return void instead.
And...patches 7-10 look straightforward and good to me.
In summary, I don't think any changes need to be made to all 10 patches
other than textual ones (commit messages, documentation, and function
names).
Patch 5 and this patch look good to me.
> @@ -1134,27 +1134,25 @@ int cmd_clone(int argc, const char **argv, const char
> *prefix)
> transport_set_option(transport, TRANS_OPT_FOLLOWTAGS, "1");
>
> if (option_upload_pack)
> transport_set_option(transport, TRANS_
> Allow combining filters such that only objects accepted by all filters
> are shown. The motivation for this is to allow getting directory
> listings without also fetching blobs. This can be done by combining
> blob:none with tree:. There are massive repositories that have
> larger-than-expected t
> Make the list-objects-filter.h API more opaque and easier to use. This
> prepares for combined filter support, where filters will be created and
> used in a new context.
>
> Helped-by: Jeff Hostetler
> Helped-by: Junio C Hamano
> Signed-off-by: Matthew DeVore
So what happens is that filter_f
> @@ -105,7 +105,7 @@ int in_same_island(const struct object_id *trg_oid, const
> struct object_id *src_
>* If we don't have a bitmap for the target, we can delta it
>* against anything -- it's not an important object
>*/
> - trg_pos = kh_get_sha1(island_marks, trg_oid-
> > @@ -230,7 +246,7 @@ static int find_common(struct fetch_negotiator
> > *negotiator,
> > if (args->stateless_rpc && multi_ack == 1)
> > die(_("--stateless-rpc requires multi_ack_detailed"));
> >
> > - for_each_ref(rev_list_insert_ref_oid, negotiator);
> > + mark_tips(negotia
> @@ -84,7 +86,7 @@ test_expect_success 'branch pointing to non-commit' '
> test_expect_success 'HEAD link pointing at a funny object' '
> test_when_finished "mv .git/SAVED_HEAD .git/HEAD" &&
> mv .git/HEAD .git/SAVED_HEAD &&
> - echo >.git/
If we want to check whether an object is missing, the correct flag to
pass to rev-list is --ignore-missing; --exclude-promisor-objects will
exclude any object that came from the promisor remote, whether it is
present or missing. Use the correct flag.
Signed-off-by: Jonathan Tan
---
t/t5616
paring the output - the
relevant line indeed shows up as uncovered on "next", and covered on
this.
Jonathan Tan (2):
t5616: use correct flag to check object is missing
t5616: cover case of client having delta base
t/t5616-partial-clone.sh | 41
slightly to cover this case.
[1] 8a30a1efd1 ("index-pack: prefetch missing REF_DELTA bases",
2019-05-15).
[2] https://public-inbox.org/git/396091fc-5572-19a5-4f18-61c258590...@gmail.com/
Signed-off-by: Jonathan Tan
---
t/t5616-partial-clone.sh | 39
of passing
with GIT_TEST_PROTOCOL_VERSION=2.
Signed-off-by: Jonathan Tan
---
With this change, all tests pass at master with
GIT_TEST_PROTOCOL_VERSION=2.
---
t/t5551-http-fetch-smart.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/t/t5551-http-fetch-smart.sh b/t/t
ich follows the documentation in this
regard.
Signed-off-by: Jonathan Tan
---
fetch-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 3f24d0c8a6..1c10f54e78 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -1115,7 +1115,7 @@ static int send_fetch
> > > Right, REF_DELTA is definitely correctly handled currently, and I don't
> > > think that would break with your patch. It's just that your patch would
> > > introduce a bunch of extra traffic as we request bases separately that
> > > are already in the pack.
> >
> > Ah...I see. For this probl
> Here is a first stab at composite filters. It does not actually support omits,
> but the biggest difficulties of the implementation are already addressed. So I
> decided to send out an early version to give interested people an idea of just
> what is needed to implement it, and then give them a c
> On Thu, May 16, 2019 at 11:26:46AM -0700, Jonathan Tan wrote:
>
> > > Pretty unlikely, but should we put some kind of circuit-breaker into the
> > > client to ensure this?
> >
> > I thought of this - such a server could, but it seems to me that it
> &
> On Tue, May 14, 2019 at 02:10:55PM -0700, Jonathan Tan wrote:
>
> > Support for lazy fetching should still generally be turned off in
> > index-pack because it is used as part of the lazy fetching process
> > itself (if not, infinite loops may occur), but we do need to
> > To resolve this, prefetch all missing REF_DELTA bases before attempting
> > to resolve them. This both ensures that all bases are attempted to be
> > fetched, and ensures that we make only one request per index-pack
> > invocation, and not one request per missing object.
>
> Hmm. I wonder whet
> > +# Converts bytes into their hexadecimal representation. For example,
> > +# "printf 'ab\r\n' | hex_unpack" results in '61620d0a'.
> > +hex_unpack () {
> > + perl -e '$/ = undef; $input = <>; print unpack("H2" x length($input),
> > $input)'
> > +}
> > +
> > +# Inserts $1 at the start of the
A subsequent patch will perform the same packfile replacement that is
already done twice, so refactor it into its own function. Also, the same
subsequent patch will use, in another way, part of the packfile
replacement functionality, so extract those out too.
Signed-off-by: Jonathan Tan
---
t
There is an issue when fetching into a partial clone, and the server
sends a REF_DELTA object that is based on a missing promisor object.
Here is a fix; more details are in the commit message of patch 2.
Jonathan Tan (2):
t5616: refactor packfile replacement
index-pack: prefetch missing
attempted to be
fetched, and ensures that we make only one request per index-pack
invocation, and not one request per missing object.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 26 +++--
t/t5616-partial-clone.sh | 61
2 fil
> > On 2019/05/07, at 11:34, Jonathan Tan wrote:
> >
> > To get an enumeration of available objects, don't you need to use only
> > "blob:none"? Combining filters (once that's implemented) will get all
> > objects only up to a certain depth.
>
> > And "official" is a phrase I have trouble with in this context. A
> > mirror does not have to be blessed as official; that's the point of
> > a mirror---anybody can make one to help users with better
> > connectivity or availability, as long as its users trust the mirror
> > maintainer for mir
> On Mon, May 06, 2019 at 03:28:44PM -0700, Jonathan Tan wrote:
> > Sorry for not looking at this sooner.
> >
> > Firstly, I'm not sure if this file should be named without the ".txt",
> > like SubmittingPatches.
>
> I should mention that during
> > My main question is: we can get the same list of objects (in the form of
> > tree objects) if we fetch with "blob:none" filter. Admittedly, we will
> > get extra data (file names, etc.) - if the extra bandwidth saving is
> > necessary, this should be called out. (And some of the savings will be
Sorry for not looking at this sooner.
Firstly, I'm not sure if this file should be named without the ".txt",
like SubmittingPatches.
As for my other comments below, the Makefile comment below is the only
one I feel strongly about; feel free to disagree with the rest (which I
think are subjective
1 - 100 of 1357 matches
Mail list logo
