Re: [PATCH v3 0/4] Improve push performance with lots of refs
On Tue, Dec 23, 2014 at 10:40:54AM -0800, Junio C Hamano wrote: You spell --thin-aggressive as two words, --thin --shallow, in this series, essentially, no? Essentially, yes. It became obligatory after I noticed the test failure, since that test actually checks whether the remote side sends a shallow-optimized pack. I think this is going in the right direction. The shallow propagated on the wire from the fetcher is the right thing to use to make this decision. I wonder if the call to is_repository_shallow() is still necessary (read: I would prefer to see it go away) where we decide between --objects-edge and --objects-edge-aggressive. Okay. I'll try to push it up the stack a little bit. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
[PATCH v3 0/4] Improve push performance with lots of refs
This series contains patches to address a significant push performance regression in repositories with large amounts of refs. It avoids performing expensive edge marking unless the repository is shallow. The first patch in the series is a fix for a minor typo I discovered when editing the documentation. The second patch implements git rev-list --objects-edge-aggressive, and the third patch ensures it's used for shallow repos only. The final patch ensures that sending packs to shallow clients use --object-edge-aggressive as well. The only change from v2 is the addition of a fourth patch, which fixes t5500. It's necessary because the test wants packs for fetches to shallow clones to be minimal. I'm not especially thrilled with having to provide a --shallow command line argument, but the alternative is to buffer a potentially large amount of data in order to determine whether the remote side is shallow. The original fix was suggested by Duy Nguyen. brian m. carlson (4): Documentation: add missing article in rev-list-options.txt rev-list: add an option to mark fewer edges as uninteresting pack-objects: use --objects-edge-aggressive only for shallow repos upload-pack: use --objects-edge-aggressive for shallow fetches Documentation/git-pack-objects.txt | 7 ++- Documentation/git-rev-list.txt | 3 ++- Documentation/rev-list-options.txt | 7 ++- builtin/pack-objects.c | 7 ++- list-objects.c | 4 ++-- revision.c | 6 ++ revision.h | 1 + upload-pack.c | 4 +++- 8 files changed, 32 insertions(+), 7 deletions(-) -- 2.2.1.209.g41e5f3a -- 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
Re: [PATCH v3 0/4] Improve push performance with lots of refs
brian m. carlson sand...@crustytoothpaste.net writes:
The only change from v2 is the addition of a fourth patch, which fixes
t5500. It's necessary because the test wants packs for fetches to
shallow clones to be minimal.
I'm not especially thrilled with having to provide a --shallow command
line argument, but the alternative is to buffer a potentially large
amount of data in order to determine whether the remote side is shallow.
You spell --thin-aggressive as two words, --thin --shallow, in
this series, essentially, no?
I think this is going in the right direction. The shallow
propagated on the wire from the fetcher is the right thing to use
to make this decision.
I wonder if the call to is_repository_shallow() is still necessary
(read: I would prefer to see it go away) where we decide between
--objects-edge and --objects-edge-aggressive.
Here is the relevant part from 4/4:
@@ -2711,7 +2714,7 @@ int cmd_pack_objects(int argc, const char **argv, const
char *prefix)
argv_array_push(rp, pack-objects);
if (thin) {
use_internal_rev_list = 1;
- argv_array_push(rp, is_repository_shallow()
+ argv_array_push(rp, is_repository_shallow() || shallow
? --objects-edge-aggressive
: --objects-edge);
} else
--
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
