This series attempts to reduce the cost of check_everything_connected
on the clone case where index-pack is run. For example, cloning
file://../linux-2.6.git:
    
        before       after
real    4m23.664s    3m47.280s
user    4m55.613s    4m39.530s
sys     0m14.805s    0m17.728s

The first three patches are improvements or fixes and I think they're
good to go (if no bugs are found). The last two introduce
--not-so-strict as check_everything_connected replacement and use it
where applicable and are debatable (I guess).

The reroll fixes shallow file update issue Junio pointed out
previously. It also does not remove check_everything_connected unless
it knows that index-pack or unpack-objects are run with
--not-so-strict.

Nguyễn Thái Ngọc Duy (5):
  clone: let the user know when check_everything_connected is run
  fetch-pack: prepare updated shallow file before fetching the pack
  index-pack: remove dead code (it should never happen)
  index-pack, unpack-objects: add --not-so-strict for connectivity check
  Use --not-so-strict on all pack transfer for connectivity check

 Documentation/git-index-pack.txt     |  3 ++
 Documentation/git-unpack-objects.txt |  4 +++
 builtin/clone.c                      | 18 +++++++---
 builtin/fetch.c                      | 11 +++---
 builtin/index-pack.c                 | 10 ++++--
 builtin/receive-pack.c               | 51 +++------------------------
 builtin/unpack-objects.c             |  9 +++--
 commit.h                             |  1 +
 fetch-pack.c                         | 67 ++++++++++++++++++------------------
 fetch-pack.h                         |  3 +-
 shallow.c                            | 30 ++++++++++++++--
 t/t5500-fetch-pack.sh                |  7 ++++
 t/t5504-fetch-receive-strict.sh      |  2 +-
 transport.c                          |  2 ++
 transport.h                          |  1 +
 15 files changed, 120 insertions(+), 99 deletions(-)

-- 
1.8.2.83.gc99314b

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to