Re: [PATCH v8 08/14] commit-graph: implement git commit-graph read

On Sat, Apr 14, 2018 at 6:15 PM, Jakub Narebski wrote: > Derrick Stolee writes: >> + NUM_CHUNKS=$((3 + $(echo "$2" | wc -w))) > > I don't know if it is possible to do the above in a portable shell > without using external 'wc' command. Also, isn't

[PATCH] t1510-repo-setup.sh: rm useless mkdir

From: Tao Qingyun <845767...@qq.com> Signed-off-by: Tao Qingyun <845767...@qq.com> --- t/t1510-repo-setup.sh | 1 - 1 file changed, 1 deletion(-) diff --git a/t/t1510-repo-setup.sh b/t/t1510-repo-setup.sh index e6854b828..972bd9c78 100755 --- a/t/t1510-repo-setup.sh +++ b/t/t1510-repo-setup.sh

Request for Quotation

Hello, Good day, I am Mohammed, Our company is interested in your product. We have gone through your product site online and wish to make order of your product. Please do send us details of your products and company to our {email} Also provide with the recent price We await your response

Re: [PATCH 0/7] nd/repack-keep-pack update

On Sun, Apr 15, 2018 at 4:47 AM, Ævar Arnfjörð Bjarmason wrote: > > The only (trivial) issue I found in the patches themselves was that > between 4/5 and 5/7 you're adding an empty line to config.txt in 4/7 > just to erase it in 5/7, better not to add it to begin with, but >

Re: [PATCH v8 08/14] commit-graph: implement git commit-graph read

Derrick Stolee writes: > From: Derrick Stolee > Subject: [PATCH v8 08/14] commit-graph: implement git commit-graph read Minor nit: this is one commit message [subject] among all others that uses "git commit-graph" instead of "git-commit-graph" in the

Re: Feature Request: Add diff.word-diff and perhaps diff.word-diff-regex configuration options to enable always using word-diffs in git diff

On Sat, Apr 14 2018, Doron Behar wrote: > I've just came across the wonderful command line option for `git diff`: > `--word-diff`. It could be great to have a configuration option that > will enable this feature by default when running `git diff`. Do you know you can do: git config

Feature Request: Add diff.word-diff and perhaps diff.word-diff-regex configuration options to enable always using word-diffs in git diff

I've just came across the wonderful command line option for `git diff`: `--word-diff`. It could be great to have a configuration option that will enable this feature by default when running `git diff`. signature.asc Description: PGP signature

Re: [PATCH 8/8] gpg-interface: handle alternative signature types

On Tue, Apr 10, 2018 at 04:24:27AM -0400, Eric Sunshine wrote: > How confident are we that _all_ possible signing programs will conform > to the "-BEGIN %s-" pattern? If we're not confident, then > perhaps the user should be providing the full string here, not just > the '%s' part? This

Re: [PATCH 01/15] read-cache.c: make $GIT_TEST_SPLIT_INDEX boolean

On Sat, Apr 14 2018, Nguyễn Thái Ngọc Duy wrote: > While at there, document about this special mode when running the test > suite. This whole series looks good to me, and I see this patch addressed the confusing test env variable situation I pointed out in v8

Re: [PATCH 0/7] nd/repack-keep-pack update

On Sat, Apr 14 2018, Nguyễn Thái Ngọc Duy wrote: > This is basically a resend from the last round but rebased on > 'master'. The old base results in some conflicts with packfile and oid > conversion series. This one should reduce merge conflicts on 'pu' to > trivial ones. Thanks. I've been

Re: [RFC PATCH] tests: fix PATH for GIT_TEST_INSTALLED tests

Hi Joannnes, Le 14 avril 2018 14:30:38 UTC+02:00, Johannes Schindelin a écrit : >Hi Guillaume, > >On Sat, 14 Apr 2018, Guillaume Maudoux wrote: > >> From: Guillaume Maudoux >> >> When running tests on an existing git installation with >>

[PATCH v4 2/4] Makefile: detect compiler and enable more warnings in DEVELOPER=1

From: Nguyễn Thái Ngọc Duy The set of extra warnings we enable when DEVELOPER has to be conservative because we can't assume any compiler version the developer may use. Detect the compiler version so we know when it's safe to enable -Wextra and maybe more. These warning

[PATCH v4 4/4] Makefile: add a DEVOPTS to get all of -Wextra

Change DEVOPTS to understand a "extra-all" option. When the DEVELOPER flag is enabled we turn on -Wextra, but manually switch some of the warnings it turns on off. This is because we have many existing occurrences of them in the code base. This mode will stop the suppression, let the developer

[PATCH v4 3/4] Makefile: add a DEVOPTS to suppress -Werror under DEVELOPER

Add a DEVOPTS variable that'll be used to tweak the behavior of DEVELOPER. I've long wanted to use DEVELOPER=1 in my production builds, but on some old systems I still get warnings, and thus the build would fail. However if the build/tests fail for some other reason, it would still be useful to

[PATCH v4 1/4] connect.c: mark die_initial_contact() NORETURN

From: Nguyễn Thái Ngọc Duy There is a series running in parallel with this one that adds code like this switch (...) { case ...: die_initial_contact(); case ...: There is nothing wrong with this. There is no actual falling through. But since gcc is not

[PATCH v4 0/4] Make DEVELOPER more more flexible with DEVOPTS

This is a v4 and replacement of gitster/nd/warn-more-for-devs. I'm sending this with Duy's blessing. The first two patches are the same, except for one trivial s/faimily/family/ typo fix. The third patch in gitster/nd/warn-more-for-devs ("Makefile: add EAGER_DEVELOPER mode") is gone, instead

Re: [PATCH v8 09/14] commit-graph: add core.commitGraph setting

Derrick Stolee writes: > From: Derrick Stolee > > The commit graph feature is controlled by the new core.commitGraph config > setting. This defaults to 0, so the feature is opt-in. > > The intention of core.commitGraph is that a user can always stop

Re: [PATCH 0/6] Compute and consume generation numbers

Derrick Stolee writes: > On 4/11/2018 3:32 PM, Jakub Narebski wrote: >> What would you suggest as a good test that could imply performance? The >> Google Colab notebook linked to above includes a function to count >> number of commits (nodes / vertices in the commit graph)

Re: Need help debugging issue in git

On Mon, Apr 2, 2018 at 1:53 AM, Johannes Sixt wrote: > Am 02.04.2018 um 02:36 schrieb Robert Dailey: >> >> I'm struggling with a bug that I found introduced in git v2.13.2. The >> bug was not reproducible in v2.13.1. The issue is that using arguments >> like "@{-1}" to aliases

Re: [PATCH v1 0/2] fsexcludes: Add programmatic way to exclude files

On Tue, Apr 10, 2018 at 11:04 PM, Ben Peart wrote: > In git repos with large working directories an external file system monitor > (like fsmonitor or gvfs) can track what files in the working directory have > been > modified. This information can be used to speed up git

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

On Thu, Apr 12, 2018 at 12:06 AM, Philip Oakley wrote: > I'm only just catching up, but does/can this series also capture the > non-command guides that are available in git so that the 'git help -g' can > begin to list them all? It currently does not. But I don't see why it

[PATCH 06/15] pack-objects: move in_pack_pos out of struct object_entry

This field is only need for pack-bitmap, which is an optional feature. Move it to a separate array that is only allocated when pack-bitmap is used (like objects[], it is not freed, since we need it until the end of the process) Signed-off-by: Nguyễn Thái Ngọc Duy ---

[PATCH 11/15] pack-objects: clarify the use of object_entry::size

While this field most of the time contains the canonical object size, there is one case it does not: when we have found that the base object of the delta in question is also to be packed, we will very happily reuse the delta by copying it over instead of regenerating the new delta. "size" in this

[PATCH 12/15] pack-objects: shrink size field in struct object_entry

It's very very rare that an uncompressed object is larger than 4GB (partly because Git does not handle those large files very well to begin with). Let's optimize it for the common case where object size is smaller than this limit. Shrink size field down to 31 bits and one overflow bit. If the

[PATCH 03/15] pack-objects: turn type and in_pack_type to bitfields

An extra field type_valid is added to carry the equivalent of OBJ_BAD in the original "type" field. in_pack_type always contains a valid type so we only need 3 bits for it. A note about accepting OBJ_NONE as "valid" type. The function read_object_list_from_stdin() can pass this value [1] and it

[PATCH 08/15] pack-objects: refer to delta objects by index instead of pointer

These delta pointers always point to elements in the objects[] array in packing_data struct. We can only hold maximum 4G of those objects because the array size in nr_objects is uint32_t. We could use uint32_t indexes to address these elements instead of pointers. On 64-bit architecture (8 bytes

[PATCH 07/15] pack-objects: move in_pack out of struct object_entry

Instead of using 8 bytes (on 64 bit arch) to store a pointer to a pack. Use an index instead since the number of packs should be relatively small. This limits the number of packs we can handle to 1k. Since we can't be sure people can never run into the situation where they have more than 1k pack

[PATCH 10/15] pack-objects: don't check size when the object is bad

sha1_object_info() in check_objects() may fail to locate an object in the pack and return type OBJ_BAD. In that case, it will likely leave the "size" field untouched. We delay error handling until later in prepare_pack() though. Until then, do not touch "size" field. This field should contain the

[PATCH 05/15] pack-objects: use bitfield for object_entry::depth

Because of struct packing from now on we can only handle max depth 4095 (or even lower when new booleans are added in this struct). This should be ok since long delta chain will cause significant slow down anyway. Signed-off-by: Nguyễn Thái Ngọc Duy ---

[PATCH 09/15] pack-objects: shrink z_delta_size field in struct object_entry

We only cache deltas when it's smaller than a certain limit. This limit defaults to 1000 but save its compressed length in a 64-bit field. Shrink that field down to 20 bits, so you can only cache 1MB deltas. Larger deltas must be recomputed at when the pack is written down. Signed-off-by: Nguyễn

[PATCH 13/15] pack-objects: shrink delta_size field in struct object_entry

Allowing a delta size of 64 bits is crazy. Shrink this field down to 20 bits with one overflow bit. If we find an existing delta larger than 1MB, we do not cache delta_size at all and will get the value from oe_size(), potentially from disk if it's larger than 4GB. Note, since DELTA_SIZE() is

[PATCH 15/15] ci: exercise the whole test suite with uncommon code in pack-objects

Some recent optimizations have been added to pack-objects to reduce memory usage and some code paths are split into two: one for common use cases and one for rare ones. Make sure the rare cases are tested with Travis since it requires manual test configuration that is unlikely to be done by

[PATCH 14/15] pack-objects: reorder members to shrink struct object_entry

Previous patches leave lots of holes and padding in this struct. This patch reorders the members and shrinks the struct down to 80 bytes (from 136 bytes on 64-bit systems, before any field shrinking is done) with 16 bits to spare (and a couple more in in_pack_header_size when we really run out of

[PATCH 01/15] read-cache.c: make $GIT_TEST_SPLIT_INDEX boolean

While at there, document about this special mode when running the test suite. Signed-off-by: Nguyễn Thái Ngọc Duy --- ci/run-build-and-tests.sh | 2 +- read-cache.c | 4 ++-- t/README | 11 +++ 3 files changed, 14 insertions(+), 3

[PATCH 02/15] pack-objects: a bit of document about struct object_entry

The role of this comment block becomes more important after we shuffle fields around to shrink this struct. It will be much harder to see what field is related to what. Signed-off-by: Nguyễn Thái Ngọc Duy --- pack-objects.h | 45 +

[PATCH 04/15] pack-objects: use bitfield for object_entry::dfs_state

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/pack-objects.c | 3 +++ pack-objects.h | 28 +--- 2 files changed, 20 insertions(+), 11 deletions(-) diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index 88877f1f59..cc3c31747e

[PATCH 00/15] nd/pack-objects-pack-struct update

This is basically a resend from the last round but rebased on latest master to take advantage of new object-store and oid changes. One minor change is t/README now mentions about git-config when a variable accepts a boolean value. Nguyễn Thái Ngọc Duy (15): read-cache.c: make

[PATCH 0/7] nd/repack-keep-pack update

This is basically a resend from the last round but rebased on 'master'. The old base results in some conflicts with packfile and oid conversion series. This one should reduce merge conflicts on 'pu' to trivial ones. Nguyễn Thái Ngọc Duy (7): t7700: have closing quote of a test at the beginning

[PATCH 1/7] t7700: have closing quote of a test at the beginning of line

The closing quote of a test body by convention is always at the start of line. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- t/t7700-repack.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7700-repack.sh

[PATCH 5/7] gc: handle a corner case in gc.bigPackThreshold

This config allows us to keep packs back if their size is larger than a limit. But if this N >= gc.autoPackLimit, we may have a problem. We are supposed to reduce the number of packs after a threshold because it affects performance. We could tell the user that they have incompatible

[PATCH 6/7] gc --auto: exclude base pack if not enough mem to "repack -ad"

pack-objects could be a big memory hog especially on large repos, everybody knows that. The suggestion to stick a .keep file on the giant base pack to avoid this problem is also known for a long time. Recent patches add an option to do just this, but it has to be either configured or activated

[PATCH 4/7] gc: add gc.bigPackThreshold config

The --keep-largest-pack option is not very convenient to use because you need to tell gc to do this explicitly (and probably on just a few large repos). Add a config key that enables this mode when packs larger than a limit are found. Note that there's a slight behavior difference compared to

[PATCH 7/7] pack-objects: show some progress when counting kept objects

We only show progress when there are new objects to be packed. But when --keep-pack is specified on the base pack, we will exclude most of objects. This makes 'pack-objects' stay silent for a long time while the counting phase is going. Let's show some progress whenever we visit an object

[PATCH 2/7] repack: add --keep-pack option

We allow to keep existing packs by having companion .keep files. This is helpful when a pack is permanently kept. In the next patch, git-gc just wants to keep a pack temporarily, for one pack-objects run. git-gc can use --keep-pack for this use case. A note about why the pack_keep field cannot be

[PATCH 3/7] gc: add --keep-largest-pack option

This adds a new repack mode that combines everything into a secondary pack, leaving the largest pack alone. This could help reduce memory pressure. On linux-2.6.git, valgrind massif reports 1.6GB heap in "pack all" case, and 535MB in "pack all except the base pack" case. We save roughly 1GB

Re: [PATCH] completion: reduce overhead of clearing cached --options

SZEDER Gábor writes: > On Fri, Apr 13, 2018 at 11:44 PM, Jakub Narebski wrote: >> SZEDER Gábor writes: >>> >>> In Bash we can do better: run the 'compgen -v __gitcomp_builtin_' >>> builtin command, which lists the same variables, but

Re: Bug: rebase -i creates committer time inversions on 'reword'

Hi, On Sat, 14 Apr 2018, Phillip Wood wrote: > On 13/04/18 17:52, Johannes Sixt wrote: > > > > I just noticed that all commits in a 70-commit branch have the same > > committer timestamp. This is very unusual on Windows, where rebase -i of > > such a long branch takes more than one second (but

Re: [RFC PATCH] tests: fix PATH for GIT_TEST_INSTALLED tests

Hi Guillaume, On Sat, 14 Apr 2018, Guillaume Maudoux wrote: > From: Guillaume Maudoux > > When running tests on an existing git installation with > GIT_TEST_INSTALLED (as described in t/README), the test helpers are > missing in the PATH. > > This fixes the test suite in a

Re: Bug: rebase -i creates committer time inversions on 'reword'

On 13/04/18 17:52, Johannes Sixt wrote: > > I just noticed that all commits in a 70-commit branch have the same > committer timestamp. This is very unusual on Windows, where rebase -i of > such a long branch takes more than one second (but not more than 3 or > so thanks to the builtin nature of

Gruß

Gruß In einer kurzen Einleitung bin ich der Anwalt Vladimir Volf aus zamberk Tschechische Republik, aber jetzt lebe ich in London, ich habe dir eine E-Mail über meinen verstorbenen Klienten geschickt, aber ich habe keine Antwort von dir erhalten, der Verstorbene ist ein Bürger Von deinem Land mit