[PATCH v4 3/3] diff: define block by number of alphanumeric chars

h as those solely consisting of one or a few closing braces), as was the intention of the adjacent-moved-line heuristic. This requires a change in some tests in that some of their lines are no longer considered to be part of a block, because they are too short. Signed-off-by: Jonathan Tan &

[PATCH v4 2/3] diff: respect MIN_BLOCK_LENGTH for last block

Currently, MIN_BLOCK_LENGTH is only checked when diff encounters a line that does not belong to the current block. In particular, this means that MIN_BLOCK_LENGTH is not checked after all lines are encountered. Perform that check. Signed-off-by: Jonathan Tan <jonathanta...@google.

[PATCH v4 1/3] diff: avoid redundantly clearing a flag

No code in diff.c sets DIFF_SYMBOL_MOVED_LINE except in mark_color_as_moved(), so it is redundant to clear it for the current line. Therefore, clear it only for previous lines. This makes a refactoring in a subsequent patch easier. Signed-off-by: Jonathan Tan <jonathanta...@google.

[PATCH v4 0/3] "diff --color-moved" with yet another heuristic

if the parent function provides that information, since it already tracks that. In addition, we avoid corner cases such as what happens if the block is at the start of the diff output (we must ensure that we don't read off the beginning edge, for example). Jonathan Tan (3): diff: avoid redundantly

[RFC PATCH] Updated "imported object" design

the new state of affairs. In this commit, teach fsck that promises referenced from the reflog are not an error case; in future commits, fsck will be taught about other cases. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- Documentation/technical/repository-version.txt |

Re: [PATCH] sub-process: print the cmd when a capability is unsupported

On Tue, 15 Aug 2017 19:36:11 +0200 Christian Couder wrote: > In handshake_capabilities() we use warning() when a capability > is not supported, so the exit code of the function is 0 and no > further error is shown. This is a problem because the warning > message

[PATCH v3 3/3] diff: define block by number of non-space chars

e observed, however. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- Documentation/diff-options.txt | 8 ++-- diff.c | 27 +--- diff.h | 2 +- t/t4015-diff-whitespace.sh | 96 +++--- 4 fi

[PATCH v3 0/3] "diff --color-moved" with different heuristic

. As for the test, good point about testing the boundary conditions - I have included another test that does that. Jonathan Tan (3): diff: avoid redundantly clearing a flag diff: respect MIN_BLOCK_LENGTH for last block diff: define block by number of non-space chars Documentation/diff

[PATCH v3 1/3] diff: avoid redundantly clearing a flag

No code in diff.c sets DIFF_SYMBOL_MOVED_LINE except in mark_color_as_moved(), so it is redundant to clear it for the current line. Therefore, clear it only for previous lines. This makes a refactoring in a subsequent patch easier. Signed-off-by: Jonathan Tan <jonathanta...@google.

[PATCH v3 2/3] diff: respect MIN_BLOCK_LENGTH for last block

Currently, MIN_BLOCK_LENGTH is only checked when diff encounters a line that does not belong to the current block. In particular, this means that MIN_BLOCK_LENGTH is not checked after all lines are encountered. Perform that check. Signed-off-by: Jonathan Tan <jonathanta...@google.

[PATCH v2 3/3] diff: check MIN_BLOCK_LENGTH at start of new block

subsequent test where the non-malicious change is marked with move colors. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- Documentation/diff-options.txt | 6 ++-- diff.c | 6 +++- t/t4015-diff-whitespace.sh | 71 +--

[PATCH v2 0/3] Fixes to "diff --color-moved" MIN_BLOCK_LENGTH handling

correct, I can send another patch to update the documentation to be less ambiguous and maybe update the code to not use a name like MIN_BLOCK_LENGTH, as it is the number of adjacent moved lines that we are checking, not the length of a block.) Jonathan Tan (3): diff: avoid redundantly clearing a f

[PATCH v2 1/3] diff: avoid redundantly clearing a flag

No code in diff.c sets DIFF_SYMBOL_MOVED_LINE except in mark_color_as_moved(), so it is redundant to clear it for the current line. Therefore, clear it only for previous lines. This makes a refactoring in a subsequent patch easier. Signed-off-by: Jonathan Tan <jonathanta...@google.

[PATCH v2 2/3] diff: respect MIN_BLOCK_LENGTH for last block

Currently, MIN_BLOCK_LENGTH is only checked when diff encounters a line that does not belong to the current block. In particular, this means that MIN_BLOCK_LENGTH is not checked after all lines are encountered. Perform that check. Signed-off-by: Jonathan Tan <jonathanta...@google.

[RFC PATCH 1/3] diff: avoid redundantly clearing a flag

No code in diff.c sets DIFF_SYMBOL_MOVED_LINE except in mark_color_as_moved(), so it is redundant to clear it for the current line. Therefore, clear it only for previous lines. This makes a refactoring in a subsequent patch easier. Signed-off-by: Jonathan Tan <jonathanta...@google.

[RFC PATCH 0/3] Fixes to "diff --color-moved" MIN_BLOCK_LENGTH handling

, and in my work, I would also like the rules to be relaxed. What do you think of also changing the rule to, say, "minimum 10 non-whitespace characters"? [1] https://public-inbox.org/git/cover.1502483486.git.jonathanta...@google.com/ Jonathan Tan (3): diff: avoid redundantly clearing

[RFC PATCH 2/3] diff: respect MIN_BLOCK_LENGTH for last block

Currently, MIN_BLOCK_LENGTH is only checked when diff encounters a line that does not belong to the current block. In particular, this means that MIN_BLOCK_LENGTH is not checked after all lines are encountered. Perform that check. Signed-off-by: Jonathan Tan <jonathanta...@google.

[RFC PATCH 3/3] diff: check MIN_BLOCK_LENGTH at start of new block

When noticing that the current line is not the continuation of the current block, but the start of a new one, mark_color_as_moved() does not check the length of the current block. Perform that check. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- diff.c

[PATCH 0/2] non-move patches in preparation for packfile.c

ot;pu" and resolving the conflicts, I noticed some "zebra stripes" (from --color-moved) where I didn't expect time. I'll try to figure out that issue before I resend the rest of the patches (which will be after the relevant branches are merged to "next"). Jonathan Tan (2): sha1_file:

[PATCH 2/2] sha1_file: remove read_packed_sha1()

Use read_object() in its place instead. This avoids duplication of code. This makes force_object_loose() slightly slower (because of a redundant check of loose object storage), but only in the error case. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- sha1_file.

[PATCH 1/2] sha1_file: set whence in storage-specific info fn

lta base cache, will be moved to a separate file. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- sha1_file.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index b60ae15f7..910109fd9 100644 --- a/sha1_file.c +++ b/sh

Re: [PATCH v2 00/25] Move exported packfile funcs to its own file

On Thu, 10 Aug 2017 14:19:59 -0700 Junio C Hamano <gits...@pobox.com> wrote: > Jonathan Tan <jonathanta...@google.com> writes: > > > Here is the complete patch set. I have only moved the exported functions > > that operate with packfiles and their static hel

Re: [PATCH 3/5] interpret-trailers: add an option to show only existing trailers

On Wed, 9 Aug 2017 08:24:40 -0400 Jeff King wrote: > diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh > index e5b0718ef6..525fd53e5b 100755 > --- a/t/t7513-interpret-trailers.sh > +++ b/t/t7513-interpret-trailers.sh > @@ -1312,4 +1312,19 @@

Re: [PATCH 2/5] interpret-trailers: add an option to show only the trailers

On Wed, 9 Aug 2017 08:24:03 -0400 Jeff King wrote: > diff --git a/trailer.c b/trailer.c > index 0a0c2c264d..a4ff99f98a 100644 > --- a/trailer.c > +++ b/trailer.c > @@ -164,13 +164,15 @@ static void print_tok_val(FILE *outfile, const char > *tok, const char *val) >

Re: [RFC PATCH 01/10] pack: move pack name-related functions

On Wed, 9 Aug 2017 14:00:40 +0200 Christian Couder <christian.cou...@gmail.com> wrote: > On Tue, Aug 8, 2017 at 10:50 PM, Jonathan Tan <jonathanta...@google.com> > wrote: > > On Tue, 8 Aug 2017 13:36:24 -0700 > > Stefan Beller <sbel...@google.com> wrote: >

[PATCH v2 10/25] pack: move install_packed_git()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 1 - pack.h | 4 ++-- packfile.c | 11 ++- sha1_file.c | 9 - 4 files changed, 12 insertions(+), 13 deletions(-) diff --git a/cache.h b/cache.h index bf93477e8..41562dc0b 100644 --- a/cache.h

[PATCH v2 06/25] pack: move pack-closing functions

The function close_pack_fd() needs to be temporarily made global. Its scope will be restored to static in a subsequent commit. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/am.c| 1 + builtin/clone.c | 1 + builtin/fetch.c | 1 + builtin/merge.c | 1 + c

[PATCH v2 11/25] pack: move {,re}prepare_packed_git and approximate_object_count

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/gc.c | 1 + cache.h| 15 http-backend.c | 1 + pack.h | 15 packfile.c | 216 + path.c | 1 + server-info.c

[PATCH v2 12/25] pack: move unpack_object_header()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 1 - pack.h | 2 ++ packfile.c | 25 + sha1_file.c | 25 - 4 files changed, 27 insertions(+), 26 deletions(-) diff --git a/cache.h b/cache.h index f020dfade..9c7

[PATCH v2 09/25] pack: move add_packed_git()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 1 - connected.c | 1 + pack.h | 1 + packfile.c | 53 + sha1_file.c | 61 - 5 files chang

[PATCH v2 20/25] pack: move find_pack_entry_one(), is_pack_valid()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 8 -- pack.h | 10 ++-- packfile.c | 85 + sha1_file.c | 84 4 files chang

[PATCH v2 21/25] pack: move find_sha1_pack()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 3 --- http-push.c | 1 + http-walker.c | 1 + pack.h| 3 +++ packfile.c| 13 + sha1_file.c | 13 - 6 files changed, 18 insertions(+), 16 deletions(-) diff --git a/cac

[PATCH v2 19/25] pack: move check_pack_index_ptr(), nth_packed_object_offset()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 16 pack.h | 16 packfile.c | 33 + sha1_file.c | 33 - 4 files changed, 49 insertions(+), 49 deletions(-) diff

[PATCH v2 16/25] sha1_file: remove read_packed_sha1()

Use read_object() in its place instead. This avoids duplication of code. This makes force_object_loose() slightly slower (because of a redundant check of loose object storage), but only in the error case. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- sha1_file.

[PATCH v2 18/25] pack: move nth_packed_object_{sha1,oid}

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 14 -- pack.h | 14 ++ packfile.c | 31 +++ sha1_file.c | 31 --- 4 files changed, 45 insertions(+), 45 deletions(-) diff --git a/c

[PATCH v2 15/25] sha1_file: set whence in storage-specific info fn

Move the setting of oi->whence to sha1_loose_object_info() and packed_object_info(). This allows sha1_object_info_extended() to not need to know about the delta base cache. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- sha1_file.c | 13 ++--- 1 file changed, 6 i

[PATCH v2 17/25] pack: move packed_object_info(), unpack_entry()

-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 7 - pack.h | 11 + packfile.c | 660 ++ sha1_file.c | 676 ++-- 4 files changed, 685 insertions(+), 669 del

[PATCH v2 23/25] pack: move has_sha1_pack()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/prune-packed.c | 1 + cache.h| 2 -- diff.c | 1 + pack.h | 2 ++ packfile.c | 6 ++ revision.c | 1 + sha1_file.c| 6 -- 7 files c

[PATCH v2 24/25] pack: move has_pack_index()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 2 -- pack.h | 2 ++ packfile.c | 8 sha1_file.c | 8 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/cache.h b/cache.h index d96d36d50..656b39d51 100644 --- a/cache.h +++ b/c

[PATCH v2 25/25] pack: move for_each_packed_object()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/cat-file.c | 1 + cache.h| 7 +-- pack.h | 11 +++ packfile.c | 40 reachable.c| 1 + sha1_file.c

[PATCH v2 22/25] pack: move find_pack_entry() and make it global

This function needs to be global as it is used by sha1_file.c and will be used by packfile.c. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- pack.h | 2 ++ packfile.c | 53 + sha1_file.

[PATCH v2 01/25] pack: move pack name-related functions

pack.h to hold these packfile-related functions. In this commit, the pack name-related functions are moved. Subsequent commits will move the other functions. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- Makefile | 1 + builtin/pack-redundant.c | 1 + c

[PATCH v2 02/25] pack: move static state variables

sha1_file.c declares some static variables that store packfile-related state. Move them to packfile.c. They are temporarily made global, but subsequent commits will restore their scope back to static. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- pack.h

[PATCH v2 00/25] Move exported packfile funcs to its own file

that are temporarily made global, but reduced back to static when the wide scope is no longer needed.) Jonathan Tan (25): pack: move pack name-related functions pack: move static state variables pack: move pack_report() pack: move open_pack_index(), parse_pack_index() pack: move

[PATCH v2 08/25] pack: move unuse_pack()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 1 - pack.h | 1 + packfile.c | 9 + sha1_file.c | 9 - 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/cache.h b/cache.h index dd9f9a9ae..4812f3a63 100644 --- a/cache.h +++ b/c

[PATCH v2 14/25] pack: move unpack_object_header()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 1 - pack.h | 1 + packfile.c | 26 ++ sha1_file.c | 26 -- 4 files changed, 27 insertions(+), 27 deletions(-) diff --git a/cache.h b/cache.h index e29

[PATCH v2 03/25] pack: move pack_report()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 2 -- pack.h | 2 ++ packfile.c | 24 sha1_file.c | 24 4 files changed, 26 insertions(+), 26 deletions(-) diff --git a/cache.h b/cache.h index 1f0f47819..c7f

[PATCH v2 05/25] pack: move release_pack_memory()

The function unuse_one_window() needs to be temporarily made global. Its scope will be restored to static in a subsequent commit. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- git-compat-util.h | 2 -- pack.h| 4 packfile.c

[PATCH v2 13/25] pack: move get_size_from_delta()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 1 - pack.h | 1 + packfile.c | 40 sha1_file.c | 39 --- 4 files changed, 41 insertions(+), 40 deletions(-) diff --git a/cac

[PATCH v2 04/25] pack: move open_pack_index(), parse_pack_index()

alloc_packed_git() in packfile.c is duplicated from sha1_file.c. In a subsequent commit, alloc_packed_git() will be removed from sha1_file.c. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/count-objects.c | 1 + cache.h | 8 ---

[PATCH v2 07/25] pack: move use_pack()

The function open_packed_git() needs to be temporarily made global. Its scope will be restored to static in a subsequent commit. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 1 - pack.h | 14 +-- packfile.c

Re: [RFC PATCH 01/10] pack: move pack name-related functions

On Tue, 8 Aug 2017 13:36:24 -0700 Stefan Beller <sbel...@google.com> wrote: > On Tue, Aug 8, 2017 at 12:32 PM, Jonathan Tan <jonathanta...@google.com> > wrote: > > Currently, sha1_file.c and cache.h contain many functions, both related > > to and unrelated to pa

Re: [RFC PATCH 04/10] pack: move open_pack_index(), parse_pack_index()

On Tue, 08 Aug 2017 13:19:23 -0700 Junio C Hamano <gits...@pobox.com> wrote: > Jonathan Tan <jonathanta...@google.com> writes: > > > Signed-off-by: Jonathan Tan <jonathanta...@google.com> > > --- > > builtin/count-objects.c | 1 + > >

Re: [RFC PATCH 00/10] An attempt to move packfile funcs to its own file

On Tue, 08 Aug 2017 13:05:05 -0700 Junio C Hamano <gits...@pobox.com> wrote: > Jonathan Tan <jonathanta...@google.com> writes: > > > While investigating annotating packfiles and loose objects to support > > connectivity checks in partial clones [1], I decided to m

[RFC PATCH 04/10] pack: move open_pack_index(), parse_pack_index()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/count-objects.c | 1 + cache.h | 8 --- pack.c | 149 pack.h | 8 +++ sha1_file.c

[RFC PATCH 08/10] pack: move unuse_pack()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 1 - pack.c | 9 + pack.h | 1 + sha1_file.c | 9 - 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/cache.h b/cache.h index dd9f9a9ae..4812f3a63 100644 --- a/cache.h +++ b/c

[RFC PATCH 10/10] pack: move install_packed_git()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 1 - pack.c | 11 ++- pack.h | 4 ++-- sha1_file.c | 9 - 4 files changed, 12 insertions(+), 13 deletions(-) diff --git a/cache.h b/cache.h index bf93477e8..41562dc0b 100644 --- a/cache.h

[RFC PATCH 00/10] An attempt to move packfile funcs to its own file

of those efforts. Is this something worth doing, and if yes, is this in the right direction? [1] https://public-inbox.org/git/20170804145113.5ceaf...@twelve2.svl.corp.google.com/ Jonathan Tan (10): pack: move pack name-related functions pack: move static state variables pack: move pack_report

[RFC PATCH 09/10] pack: move add_packed_git()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 1 - connected.c | 1 + pack.c | 53 + pack.h | 1 + sha1_file.c | 61 - 5 files chang

[RFC PATCH 03/10] pack: move pack_report()

Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- cache.h | 2 -- pack.c | 24 pack.h | 2 ++ sha1_file.c | 24 4 files changed, 26 insertions(+), 26 deletions(-) diff --git a/cache.h b/cache.h index 1f0f47819..c7f

[RFC PATCH 05/10] pack: move release_pack_memory()

The function unuse_one_window() needs to be temporarily made global. Its scope will be restored to static in a subsequent commit. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- git-compat-util.h | 2 -- pack.c| 49 +

[RFC PATCH 06/10] pack: move pack-closing functions

The function close_pack_fd() needs to be temporarily made global. Its scope will be restored to static in a subsequent commit. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- In doing this, I discovered that some builtins close the packs even though they, in theory, should no

[RFC PATCH 07/10] pack: move use_pack()

open_packed_git is made global. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- Unlike the other commits where variables and functions are made global and then remade static, open_packed_git is not remade static (because a function in sha1_file.c still uses it). --- cache.h

[RFC PATCH 02/10] pack: move static state variables

sha1_file.c declares some static variables that store packfile-related state. Move them to pack.c. They are temporarily made global, but subsequent commits will restore their scope back to static. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- pack.c | 14 ++

[RFC PATCH 01/10] pack: move pack name-related functions

to hold these packfile-related functions. In this commit, the pack name-related functions are moved. Subsequent commits will move the other functions. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- Makefile | 1 + builtin/pack-redundant.c | 1 + c

Re: Partial clone design (with connectivity check for locally-created objects)

On Mon, 7 Aug 2017 15:12:11 -0400 Ben Peart wrote: > I missed the offline discussion and so am trying to piece together what > this latest design is trying to do. Please let me know if I'm not > understanding something correctly. > > From what I can tell, objects are

Re: [PATCH for NEXT v3 2/2] sub-process: refactor handshake to common function

On Mon, 7 Aug 2017 19:51:04 +0200 Lars Schneider <larsxschnei...@gmail.com> wrote: > > > On 07 Aug 2017, at 19:21, Jonathan Tan <jonathanta...@google.com> wrote: > > > > On Sun, 6 Aug 2017 21:58:24 +0200 > > Lars Schneider <larsxschnei...@gmail.com>

Re: [PATCH v1] am: fix signoff when other trailers are present

On Mon, 07 Aug 2017 10:49:28 -0700 Junio C Hamano wrote: > Phillip Wood writes: > > > From: Phillip Wood > > > > If there was no 'Signed-off-by:' trailer but another trailer such as > > 'Reported-by:' then 'git am

Re: [PATCH for NEXT v3 2/2] sub-process: refactor handshake to common function

On Sun, 6 Aug 2017 21:58:24 +0200 Lars Schneider wrote: > > + struct cmd2process *entry = (struct cmd2process *)subprocess; > > + return subprocess_handshake(subprocess, "git-filter", versions, NULL, > > + capabilities, > > +

Re: Partial clone design (with connectivity check for locally-created objects)

On Fri, 04 Aug 2017 15:51:08 -0700 Junio C Hamano <gits...@pobox.com> wrote: > Jonathan Tan <jonathanta...@google.com> writes: > > > "Imported" objects must be in a packfile that has a ".remote" > > file with arbitrary text (similar to the

Partial clone design (with connectivity check for locally-created objects)

After some discussion in [1] (in particular, about preserving the functionality of the connectivity check as much as possible) and some in-office discussion, here's an updated design. Overview This is an update of the design in [1]. The main difference between this and other related

Re: [PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

On Wed, 02 Aug 2017 13:51:37 -0700 Junio C Hamano wrote: > > The complication is in the "git gc" operation for the case (*). > > Today, "git gc" uses a reachability walk to decide which objects to > > remove --- an object referenced by no other object is fair game to > >

Re: [PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

On Tue, 01 Aug 2017 10:11:38 -0700 Junio C Hamano wrote: > Let's step back a bit and think what already happens in the pre- > lazy-object world. We record cut-off commits when a depth limited > clone is created in "shallow". These essentially are promises, > saying something

Re: [PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

On Mon, 31 Jul 2017 14:21:56 -0700 Junio C Hamano <gits...@pobox.com> wrote: > Jonathan Tan <jonathanta...@google.com> writes: > > > Besides review changes, this patch set now includes my rewritten > > lazy-loading sha1_file patch, so you can now do this (excer

[PATCH v2 5/5] sha1_file: support loading lazy objects

if we have batching support for the most commonly used commands, but is not tolerable now for repos that exclude a large amount of objects. Helped-by: Ben Peart <benpe...@microsoft.com> Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- Documentat

[PATCH v2 4/5] fsck: support lazy objects as CLI argument

Teach fsck to not treat missing objects provided on the CLI as an error when extensions.lazyobject is set. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/fsck.c | 2 ++ t/t0410-lazy-object.sh | 16 2 files changed, 18 insertions(+) diff

[PATCH v2 2/5] fsck: support refs pointing to lazy objects

Teach fsck to not treat refs with missing targets as an error when extensions.lazyobject is set. For the purposes of warning about no default refs, such refs are still treated as legitimate refs. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/fsck.c | 8 +

[PATCH v2 1/5] environment, fsck: introduce lazyobject extension

appear whenever it is needed. Teach fsck about the new state of affairs. In this commit, teach fsck that missing objects referenced from the reflog are not an error case; in future commits, fsck will be taught about other cases. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- Documen

[PATCH v2 3/5] fsck: support referenced lazy objects

Teach fsck to not treat missing objects indirectly pointed to by refs as an error when extensions.lazyobject is set. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/fsck.c | 11 +++ t/t0410-lazy-object.sh | 27 +++ 2 files chang

[PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

d of allowing the objects to only be stored in the external database. [1] https://public-inbox.org/git/xmqqzibpn1zh@gitster.mtv.corp.google.com/ [2] https://public-inbox.org/git/20170714132651.170708-2-benpe...@microsoft.com/ [3] https://public-inbox.org/git/20170620075523.26961-1-chrisc...@tuxfa

Re: [RFC PATCH 1/4] environment, fsck: introduce lazyobject extension

On Thu, 27 Jul 2017 11:55:46 -0700 Junio C Hamano wrote: > My reading hiccupped after the first sentence, as the problem > description made it sound like this was a boolean ("are we using > lazy object feature?"), after reading "data type string". And then > "the command in

[PATCH] tests: ensure fsck fails on corrupt packfiles

t1450-fsck.sh does not have a test that checks fsck's behavior when a packfile is invalid. It does have a test for when an object in a packfile is invalid, but in that test, the packfile itself is valid. Add such a test. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- I

Re: [RFC PATCH 2/4] fsck: support refs pointing to lazy objects

On Thu, 27 Jul 2017 11:59:47 -0700 Junio C Hamano wrote: > > @@ -438,6 +438,14 @@ static int fsck_handle_ref(const char *refname, const > > struct object_id *oid, > > > > obj = parse_object(oid); > > if (!obj) { > > + if (repository_format_lazy_object) { >

Re: [RFC PATCH 3/4] fsck: support referenced lazy objects

On Thu, 27 Jul 2017 12:17:37 -0700 Junio C Hamano wrote: > The same comment as 2/4 applies here. Noted - whatever the resolution is, I'll apply it to all the patches. > > > @@ -212,6 +221,8 @@ static void check_reachable_object(struct object *obj) > > * do a full fsck >

Re: [RFC PATCH 0/4] Some patches for fsck for missing objects

On Wed, 26 Jul 2017 23:42:38 + "brian m. carlson" wrote: > I looked at this and I like the direction it's going. It's pretty > simple and straightforward, which I also like. Thanks. > What I'd recommend is that instead of making lazyObject a string, we > make

[RFC PATCH 0/4] Some patches for fsck for missing objects

into 4 patches so that you can see how the changes in fsck are being tested, but eventually these should probably be combined into 1 patch. [1] https://public-inbox.org/git/3420d9ae9ef86b78af1abe721891233e3f5865a2.1500508695.git.jonathanta...@google.com/ Jonathan Tan (4): environment, fsck

[RFC PATCH 3/4] fsck: support referenced lazy objects

Teach fsck to not treat missing objects indirectly pointed to by refs as an error when extensions.lazyobject is set. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/fsck.c | 11 +++ t/t0410-lazy-object.sh | 27 +++ 2 files chang

[RFC PATCH 2/4] fsck: support refs pointing to lazy objects

Teach fsck to not treat refs with missing targets as an error when extensions.lazyobject is set. For the purposes of warning about no default refs, such refs are still treated as legitimate refs. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/fsck.c | 8 +

[RFC PATCH 1/4] environment, fsck: introduce lazyobject extension

he command in that option. Teach fsck about the new state of affairs. In this commit, teach fsck that missing objects referenced from the reflog are not an error case; in future commits, fsck will be taught about other cases. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- Documen

[RFC PATCH 4/4] fsck: support lazy objects as CLI argument

Teach fsck to not treat missing objects provided on the CLI as an error when extensions.lazyobject is set. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- builtin/fsck.c | 2 ++ t/t0410-lazy-object.sh | 16 2 files changed, 18 insertions(+) diff

[PATCH for NEXT v3 0/2] sub-process: refactor handshake to common function

inal dash - no more gotos in expected cases (or at all) Jonathan Tan (2): Documentation: migrate sub-process docs to header sub-process: refactor handshake to common function Documentation/technical/api-sub-process.txt | 59 convert.c

[PATCH for NEXT v3 2/2] sub-process: refactor handshake to common function

file filter protocol and the new multi-file filter protocol - I have updated it to something more generic and useful. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- convert.c | 75 pkt-line.c| 19 -- pkt-line

[PATCH for NEXT v3 1/2] Documentation: migrate sub-process docs to header

Move the documentation for the sub-process API from a separate txt file to its header file. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- Documentation/technical/api-sub-process.txt | 59 - sub-process.h | 25 +

[PATCH] fsck: cleanup unused variable

Remove the unused variable "heads" from cmd_fsck(). This variable was made unused in commit c3271a0 ("fsck: do not fallback "git fsck " to "git fsck"", 2017-01-17). Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- While working on fsck, I n

[PATCH v2 0/2] sub-process: refactor handshake to common function

Changes from v1: - Moved API docs to header file - Updated documentation - Updated commit message of patch 2 to explain why the error message changed Jonathan Tan (2): Documentation: migrate sub-process docs to header sub-process: refactor handshake to common function Documentation

[PATCH v2 1/2] Documentation: migrate sub-process docs to header

Move the documentation for the sub-process API from a separate txt file to its header file. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- Documentation/technical/api-sub-process.txt | 59 - sub-process.h | 25 +

[PATCH v2 2/2] sub-process: refactor handshake to common function

file filter protocol and the new multi-file filter protocol - I have updated it to something more generic and useful. Signed-off-by: Jonathan Tan <jonathanta...@google.com> --- convert.c | 61 - pkt-line.c| 19 --- pkt-line.h

Re: [PATCH] sub-process: refactor handshake to common function

On Tue, 25 Jul 2017 10:38:51 -0400 Ben Peart wrote: > Christian Couder has been working on a similar refactoring for the perl > versions of very similar helper functions. They can be found in the > following patch series: > >

Re: fetch-any-blob / ref-in-want proposal

On Mon, Jul 24, 2017 at 12:38 PM, Orgad Shaneh wrote: > Sorry, I thought it's the same thing. I mean ref-in-want[1]. This > issue in gerrit[2] was closed, claiming that ref-in-want will solve > it. I just want to know if this is likely to be merged soon enough (I > consider

[PATCH] sub-process: refactor handshake to common function

Refactor, into a common function, the version and capability negotiation done when invoking a long-running process as a clean or smudge filter. This will be useful for other Git code that needs to interact similarly with a long-running process. Signed-off-by: Jonathan Tan <jonatha

<    2   3   4   5   6   7   8   9   10   11   >