[PATCH 10/15] rerere.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- rerere.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/rerere.c b/rerere.c index e0862e2778..810e86d246 100644 --- a/rerere.c +++ b/rerere.c @@ -524,7 +524,7 @@ static int handle_file(const char

[PATCH 05/15] diff-lib.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- diff-lib.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/diff-lib.c b/diff-lib.c index 104f954a25..56387e1f63 100644 --- a/diff-lib.c +++ b/diff-lib.c @@ -70,7 +70,7 @@ static int match_stat_with_submodule(struct diff_options

[PATCH 00/15] Kill the_index part 1, expose it

This is the beginning of the end of the_index. The problem with the_index is it lets library code anywhere access it freely. This is not good because from high level you may not realize that the_index is being used while you don't want to touch index at all, or you want to use a different index

[PATCH 11/15] revision.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- revision.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/revision.c b/revision.c index 40fd91ff2b..d56ca57717 100644 --- a/revision.c +++ b/revision.c @@ -1354,7 +1354,7 @@ void add_index_objects_to_pending(struct

[PATCH 01/15] contrib: add cocci script to replace index compat macros

Index compat macros are going to be removed to expose the_index and then reorganized to use the right index instead of simply the_index because sometimes we want to use a different index. This cocci script can help with the first step. It can be used later on on even builtin/ when we start to

[PATCH 14/15] wt-status.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- wt-status.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/wt-status.c b/wt-status.c index d1c05145a4..9859a43ec8 100644 --- a/wt-status.c +++ b/wt-status.c @@ -499,14 +499,14 @@ static int

[PATCH 13/15] sha1-name.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- sha1-name.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/sha1-name.c b/sha1-name.c index 60d9ef3c7e..8344d9a9e0 100644 --- a/sha1-name.c +++ b/sha1-name.c @@ -1560,11 +1560,11 @@ static void

[PATCH 04/15] check-racy.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- check-racy.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/check-racy.c b/check-racy.c index 24b6542352..485d7ab8f8 100644 --- a/check-racy.c +++ b/check-racy.c @@ -6,9 +6,9 @@ int main(int ac, char **av) int dirty,

[PATCH 12/15] sequencer.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- sequencer.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/sequencer.c b/sequencer.c index cca968043e..ed8af2a4cd 100644 --- a/sequencer.c +++ b/sequencer.c @@ -435,7 +435,7 @@ static struct tree

[PATCH 07/15] entry.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- entry.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/entry.c b/entry.c index 2101201a11..ec588289fb 100644 --- a/entry.c +++ b/entry.c @@ -421,7 +421,8 @@ int checkout_entry(struct cache_entry *ce, if

[PATCH 03/15] blame.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- blame.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/blame.c b/blame.c index 14d0e0b575..c357cf2f49 100644 --- a/blame.c +++ b/blame.c @@ -85,11 +85,11 @@ static void verify_working_tree_path(struct commit

[PATCH 02/15] apply.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- apply.c | 34 +++--- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/apply.c b/apply.c index d79e61591b..57a7d3cafd 100644 --- a/apply.c +++ b/apply.c @@ -3378,7 +3378,8 @@ static int verify_index_match(const

[PATCH 08/15] merge-recursive.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- merge-recursive.c | 65 --- 1 file changed, 33 insertions(+), 32 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index 5eb907f46e..2a9dfe3b33 100644 --- a/merge-recursive.c +++

[PATCH 15/15] cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch

>From now on, by default index compat macros are off because they could hide the_index dependency. Only those in builtin can use it (and even so should be avoided if possible). Signed-off-by: Nguyễn Thái Ngọc Duy --- attr.c | 1 - builtin/add.c

[PATCH 09/15] merge.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- merge.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/merge.c b/merge.c index 0783858739..21e6dc09be 100644 --- a/merge.c +++ b/merge.c @@ -36,12 +36,12 @@ int index_has_changes(struct strbuf *sb)

[PATCH 06/15] diff.c: stop using index compat macros

Signed-off-by: Nguyễn Thái Ngọc Duy --- diff.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/diff.c b/diff.c index 136d44b455..975e095ed2 100644 --- a/diff.c +++ b/diff.c @@ -3460,7 +3460,7 @@ static int reuse_worktree_file(const char *name, const struct

Re: [PATCH] unpack-trees: do not fail reset because of unmerged skipped entry

On Fri, Jun 15, 2018 at 07:42:51AM +0300, Max Kirillov wrote: > After modify/delete merge conflict happens in a file skipped by sparse > checkout, "git reset --merge", which implements the "--abort" actions, and > "git reset --hard" fail with message "Entry * not uptodate. Cannot update > sparse

Re: Hash algorithm analysis

On 14/06/18 01:58, brian m. carlson wrote: >>> I imported the optimized 64-bit implementation of KangarooTwelve. >>> The AVX2 implementation was not considered for licensing reasons >>> (it's partially generated from external code, which falls foul of >>> the GPL's "preferred form for

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

On 6/14/2018 11:44 PM, Jeff King wrote: The return value of ewah_read_mmap() is now an ssize_t, since we could (in theory) process up to 32GB of data. This would never happen in practice, but a corrupt or malicious .bitmap or index file could convince us to do so. Aside: Why a 32GB limit?

Re: [PATCH 3/3] ewah: drop ewah_serialize_native function

On 15/06/18 04:32, Jeff King wrote: > We don't call this function, and never have. The on-disk > bitmap format uses network-byte-order integers, meaning that > we cannot use the native-byte-order format written here. > > Let's drop it in the name of simplicity. Hmm, if you are in the mood to

Re: [PATCH 3/3] ewah: drop ewah_serialize_native function

On 6/15/2018 9:56 AM, Ramsay Jones wrote: On 15/06/18 04:32, Jeff King wrote: We don't call this function, and never have. The on-disk bitmap format uses network-byte-order integers, meaning that we cannot use the native-byte-order format written here. Let's drop it in the name of simplicity.

[PATCH 6/8] ewah_bitmap: delete unused 'ewah_or()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/ewah_bitmap.c | 69 -- ewah/ewok.h| 5 2 files changed, 74 deletions(-) diff --git a/ewah/ewah_bitmap.c b/ewah/ewah_bitmap.c index 3fa3edf2a3..017c677f98 100644 ---

[PATCH 3/8] ewah_bitmap: delete unused 'ewah_and()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/ewah_bitmap.c | 68 -- ewah/ewok.h| 5 2 files changed, 73 deletions(-) diff --git a/ewah/ewah_bitmap.c b/ewah/ewah_bitmap.c index b9fdda1d3d..5a4d3a6eb6 100644 ---

[PATCH 8/8] ewah_io: delete unused 'ewah_serialize_native()'

Signed-off-by: Derrick Stolee --- ewah/ewah_io.c | 26 -- ewah/ewok.h| 1 - 2 files changed, 27 deletions(-) diff --git a/ewah/ewah_io.c b/ewah/ewah_io.c index 86d3f1d02e..dde736bcd9 100644 --- a/ewah/ewah_io.c +++ b/ewah/ewah_io.c @@ -20,32 +20,6 @@ #include

[PATCH 7/8] ewah_io: delete unused 'ewah_serialize()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/ewah_io.c | 10 -- ewah/ewok.h| 1 - 2 files changed, 11 deletions(-) diff --git a/ewah/ewah_io.c b/ewah/ewah_io.c index bed1994551..86d3f1d02e 100644 --- a/ewah/ewah_io.c +++ b/ewah/ewah_io.c @@ -100,16 +100,6 @@

[PATCH 5/8] ewah_bitmap: delete unused 'ewah_not()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/ewah_bitmap.c | 19 --- ewah/ewok.h| 7 --- 2 files changed, 26 deletions(-) diff --git a/ewah/ewah_bitmap.c b/ewah/ewah_bitmap.c index 559adde37c..3fa3edf2a3 100644 --- a/ewah/ewah_bitmap.c +++

[PATCH 2/8] ewah/bitmap.c: delete unused 'bitmap_each_bit()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/bitmap.c | 24 1 file changed, 24 deletions(-) diff --git a/ewah/bitmap.c b/ewah/bitmap.c index d61dc6114a..52f1178db4 100644 --- a/ewah/bitmap.c +++ b/ewah/bitmap.c @@ -129,30 +129,6 @@ void

Re: [PATCH 8/8] ewah_io: delete unused 'ewah_serialize_native()'

On 6/15/2018 11:01 AM, Ramsay Jones wrote: On 15/06/18 15:30, Derrick Stolee wrote: Signed-off-by: Derrick Stolee --- ewah/ewah_io.c | 26 -- ewah/ewok.h| 1 - 2 files changed, 27 deletions(-) This duplicates Jeff's patch #3. Thanks. I got a bit hasty as I

Re: [PATCH v3 3/7] fetch-pack: directly end negotiation if ACK ready

Jonathan Tan writes: > When "ACK %s ready" is received, find_common() clears rev_list in an > attempt to stop further "have" lines from being sent [1]. It is much > more readable to explicitly break from the loop instead. > > So explicitly break from the loop, and make the clearing of the

[PATCH 1/8] ewah/bitmap.c: delete unused 'bitmap_clear()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/bitmap.c | 8 1 file changed, 8 deletions(-) diff --git a/ewah/bitmap.c b/ewah/bitmap.c index 756bdd050e..d61dc6114a 100644 --- a/ewah/bitmap.c +++ b/ewah/bitmap.c @@ -45,14 +45,6 @@ void bitmap_set(struct bitmap *self,

[PATCH 0/8] Delete unused methods in EWAH bitmap

The EWAH bitmap code includes several logical operations that are important for a general-purpose bitmap library. However, Git only uses the XOR operation for storing deltas between reachability bitmaps. This means that we can delete the following unused methods: * ewah_and() * ewah_and_not() *

[PATCH 4/8] ewah_bitmap: delete unused 'ewah_and_not()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/ewah_bitmap.c | 73 -- ewah/ewok.h| 5 2 files changed, 78 deletions(-) diff --git a/ewah/ewah_bitmap.c b/ewah/ewah_bitmap.c index 5a4d3a6eb6..559adde37c 100644 ---

Re: [PATCH 0/8] Delete unused methods in EWAH bitmap

On 6/15/2018 10:30 AM, Derrick Stolee wrote: The EWAH bitmap code includes several logical operations that are important for a general-purpose bitmap library. However, Git only uses the XOR operation for storing deltas between reachability bitmaps. This means that we can delete the following

Re: [BUG] git-rebase: reword squashes commits in case of merge-conflicts

On 12.06.2018 12:08, Jeff King wrote: > Thanks for a thorough report. I couldn't reproduce it on v2.17.1 on > Linux, which makes me wonder if the issue is related to git-for-windows > somehow. To the best of my knowledge (and a quick scan of "git diff" > results) the code should be the same,

Re: [PATCH 1/8] ewah/bitmap.c: delete unused 'bitmap_clear()'

On 15/06/18 15:30, Derrick Stolee wrote: > Reported-by: Ramsay Jones > Signed-off-by: Derrick Stolee > --- > ewah/bitmap.c | 8 > 1 file changed, 8 deletions(-) > > diff --git a/ewah/bitmap.c b/ewah/bitmap.c > index 756bdd050e..d61dc6114a 100644 > --- a/ewah/bitmap.c > +++

Re: [PATCH 2/8] ewah/bitmap.c: delete unused 'bitmap_each_bit()'

On 15/06/18 15:30, Derrick Stolee wrote: > Reported-by: Ramsay Jones > Signed-off-by: Derrick Stolee > --- > ewah/bitmap.c | 24 > 1 file changed, 24 deletions(-) > > diff --git a/ewah/bitmap.c b/ewah/bitmap.c > index d61dc6114a..52f1178db4 100644 > ---

Re: [PATCH 3/3] ewah: drop ewah_serialize_native function

On 15/06/18 14:56, Ramsay Jones wrote: > > > On 15/06/18 04:32, Jeff King wrote: >> We don't call this function, and never have. The on-disk >> bitmap format uses network-byte-order integers, meaning that >> we cannot use the native-byte-order format written here. >> >> Let's drop it in the

Re: [PATCH 8/8] ewah_io: delete unused 'ewah_serialize_native()'

On 15/06/18 15:30, Derrick Stolee wrote: > Signed-off-by: Derrick Stolee > --- > ewah/ewah_io.c | 26 -- > ewah/ewok.h| 1 - > 2 files changed, 27 deletions(-) This duplicates Jeff's patch #3. ATB, Ramsay Jones

Re: [PATCH 1/8] ewah/bitmap.c: delete unused 'bitmap_clear()'

On 6/15/2018 10:46 AM, Ramsay Jones wrote: On 15/06/18 15:30, Derrick Stolee wrote: Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/bitmap.c | 8 1 file changed, 8 deletions(-) diff --git a/ewah/bitmap.c b/ewah/bitmap.c index 756bdd050e..d61dc6114a 100644 ---

Re: security: potential out-of-bound read at ewah_io.c |ewah_read_mmap|

Jeff King writes: > On Fri, Jun 15, 2018 at 06:59:43AM +0800, Luat Nguyen wrote: > >> Recently, I’ve found a security issue related to out-of-bound read at >> function named `ewah_read_mmap` > > Thanks, this is definitely a bug worth addressing. But note... > >> Assume that, an attacker can put

Re: [PATCH 1/3] ewah_read_mmap: bounds-check mmap reads

SZEDER Gábor writes: >> +bitmap=$(ls .git/objects/pack/*.bitmap) && > > I think the 'ls' is unnecessary and this would do: > > bitmap=.git/objects/pack/*.bitmap Yuck. >> +test_when_finished "rm -f $bitmap" && OK, this will become "rm -f .git/objects/pack/*.bitmap" and then eval that

Re: [PATCH 1/3] ewah_read_mmap: bounds-check mmap reads

Jeff King writes: > diff --git a/ewah/ewah_io.c b/ewah/ewah_io.c > index bed1994551..33c08c40f8 100644 > --- a/ewah/ewah_io.c > +++ b/ewah/ewah_io.c > @@ -122,16 +122,23 @@ int ewah_serialize_strbuf(struct ewah_bitmap *self, > struct strbuf *sb) > return ewah_serialize_to(self,

Re: [PATCH 1/3] ewah_read_mmap: bounds-check mmap reads

On Fri, Jun 15, 2018 at 6:20 PM, Junio C Hamano wrote: > SZEDER Gábor writes: > >>> +bitmap=$(ls .git/objects/pack/*.bitmap) && >> >> I think the 'ls' is unnecessary and this would do: >> >> bitmap=.git/objects/pack/*.bitmap > > Yuck. Oh, wow, now this is embarrassing... > I said "yuck"

Re: [PATCH 1/3] ewah_read_mmap: bounds-check mmap reads

On Fri, Jun 15, 2018 at 10:05:42AM -0700, Junio C Hamano wrote: > > - memcpy(self->buffer, ptr, self->buffer_size * sizeof(eword_t)); > > - ptr += self->buffer_size * sizeof(eword_t); > > > > + data_len = st_mult(self->buffer_size, sizeof(eword_t)); > > This is a faithful conversion from

Re: [PATCH 3/3] ewah: drop ewah_serialize_native function

On Fri, Jun 15, 2018 at 10:15:50AM -0400, Derrick Stolee wrote: > > Hmm, if you are in the mood to drop ewah dead code, how about: > > > >ewah/bitmap.o - bitmap_clear > >ewah/bitmap.o - bitmap_each_bit > >ewah/ewah_bitmap.o - ewah_and > >ewah/ewah_bitmap.o -

Re: [PATCH 1/3] ewah_read_mmap: bounds-check mmap reads

On Fri, Jun 15, 2018 at 07:10:28PM +0200, SZEDER Gábor wrote: > > I said "yuck" because the original does not work if there happen to > > be more than (or for that matter, less than) one '.bitmap' file > > there. But at least as long as there is one, it should work ;-) > > Well, the test starts

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

On Fri, Jun 15, 2018 at 09:41:46AM -0700, Junio C Hamano wrote: > Derrick Stolee writes: > > > On 6/14/2018 11:44 PM, Jeff King wrote: > >> The return value of ewah_read_mmap() is now an ssize_t, > >> since we could (in theory) process up to 32GB of data. This > >> would never happen in

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

Jeff King writes: > On Thu, Jun 14, 2018 at 11:28:50PM -0400, Jeff King wrote: > >> Yep. We also fail to check if we even have enough bytes to read the >> buffer_size in the first place. >> >> Here are some patches. The first one fixes the problem you found. The >> second one drops some dead

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

Derrick Stolee writes: > On 6/14/2018 11:44 PM, Jeff King wrote: >> The return value of ewah_read_mmap() is now an ssize_t, >> since we could (in theory) process up to 32GB of data. This >> would never happen in practice, but a corrupt or malicious >> .bitmap or index file could convince us to

[PATCH] tests: clean after SANITY tests

Some of our tests try to make sure Git behaves sensibly in a read-only directory, by dropping 'w' permission bit before doing a test and then restoring it after it is done. The latter is needed for the test framework to clean after itself without leaving a leftover directory that cannot be

Re: [PATCH 3/3] ewah: drop ewah_serialize_native function

On Fri, Jun 15, 2018 at 11:33:14AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > One thing that gave me pause on ripping out more code is that I have > > some bitmap-related patches on my send-to-upstream list, and I wasn't > > sure if they used any of this code. But I checked against

Re: [PATCH v2 0/7] Delete unused methods in EWAH bitmap

On 6/15/2018 2:51 PM, Junio C Hamano wrote: Derrick Stolee writes: The EWAH bitmap code includes several logical operations that are important for a general-purpose bitmap library. However, Git only uses the XOR operation for storing deltas between reachability bitmaps. This means that we can

Re: [PATCH 0/8] ref-in-want

(replying to the original since my e-mail is about design) > This version of ref-in-want is a bit more restrictive than what Jonathan > originally proposed (only full ref names are allowed instead of globs > and OIDs), but it is meant to accomplish the same goal (solve the issues > of refs

Re: [PATCH 1/3] ewah_read_mmap: bounds-check mmap reads

Jeff King writes: > On Fri, Jun 15, 2018 at 10:05:42AM -0700, Junio C Hamano wrote: > >> > - memcpy(self->buffer, ptr, self->buffer_size * sizeof(eword_t)); >> > - ptr += self->buffer_size * sizeof(eword_t); >> >> >> > + data_len = st_mult(self->buffer_size, sizeof(eword_t)); >> >> This is

Re: [PATCH v2 0/7] Delete unused methods in EWAH bitmap

Derrick Stolee writes: >> ewah_clear() can become file-scope static, and >> rlwit_discharge_empty() can be eliminated. I do not know if either >> is worth doing, though. > > With Peff's patches, this is true. When I applied your diff to my > patch alone we could not do that. Yeah, as I

Re: [PATCH] tests: clean after SANITY tests

On Fri, Jun 15, 2018 at 2:30 PM Junio C Hamano wrote: > Some of our tests try to make sure Git behaves sensibly in a > read-only directory, by dropping 'w' permission bit before doing a > test and then restoring it after it is done. The latter is needed > for the test framework to clean after

Re: [PATCH v2 0/8] ref-in-want

Brandon Williams writes: > Changes in v2: > * issuing a want-ref line to a ref which doesn't exist is just ignored. > * fixed some typos Do I lock some (logical) prerequisite changes? On 2.18-rc2 they apply cleanly but the series fails its own test. t5703-upload-pack-ref-in-want.sh expecting

What's cooking in git.git (Jun 2018, #04; Fri, 15)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. We passed -rc2 mark; there are

Re: [PATCH v2 0/7] Delete unused methods in EWAH bitmap

On Fri, Jun 15, 2018 at 12:48:52PM -0700, Junio C Hamano wrote: > Derrick Stolee writes: > > >> ewah_clear() can become file-scope static, and > >> rlwit_discharge_empty() can be eliminated. I do not know if either > >> is worth doing, though. > > > > With Peff's patches, this is true. When I

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

On Fri, Jun 15, 2018 at 02:23:44PM -0400, Derrick Stolee wrote: > If we are considering changing the reachability bitmap, then I'm very > intrigued. I think the number one thing to consider is to use the > multi-pack-index as a reference point (with a stable object order) so the > objects can be

Re: What's cooking in git.git (Jun 2018, #04; Fri, 15)

On Fri, Jun 15, 2018 at 4:27 PM Junio C Hamano wrote: > * es/make-no-iconv (2018-06-15) 1 commit > - Makefile: make NO_ICONV really mean "no iconv" > > "make NO_ICONV=NoThanks" did not override NEEDS_LIBICONV Nit: The double-negative is a bit confusing. s/NoThanks/YesPlease/ would be easier to

Re: [PATCH v2 2/8] upload-pack: implement ref-in-want

Brandon Williams writes: > Currently, while performing packfile negotiation, clients are only > allowed to specify their desired objects using object ids. This causes > a vulnerability to failure when an object turns non-existent during > negotiation, which may happen if, for example, the

Re: [PATCH v2 2/8] upload-pack: implement ref-in-want

Junio C Hamano writes: > The story would be different if your request were > > git fetch refs/heads/*:refs/remotes/origin/* > > in which case, you are not even saying "I want this and that ref"; > you are saying "all refs in refs/heads/* whoever ends up serving me > happens to have". You

Re: [PATCH 4/3] ewah: adjust callers of ewah_read_mmap()

On 6/15/2018 1:31 PM, Jeff King wrote: On Fri, Jun 15, 2018 at 09:41:46AM -0700, Junio C Hamano wrote: Derrick Stolee writes: On 6/14/2018 11:44 PM, Jeff King wrote: The return value of ewah_read_mmap() is now an ssize_t, since we could (in theory) process up to 32GB of data. This would

[PATCH v2 7/7] ewah_io: delete unused 'ewah_serialize()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/ewah_io.c | 10 -- ewah/ewok.h| 1 - 2 files changed, 11 deletions(-) diff --git a/ewah/ewah_io.c b/ewah/ewah_io.c index bed1994551..86d3f1d02e 100644 --- a/ewah/ewah_io.c +++ b/ewah/ewah_io.c @@ -100,16 +100,6 @@

[PATCH v2 2/7] ewah/bitmap.c: delete unused 'bitmap_each_bit()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/bitmap.c | 24 ewah/ewok.h | 1 - 2 files changed, 25 deletions(-) diff --git a/ewah/bitmap.c b/ewah/bitmap.c index d61dc6114a..52f1178db4 100644 --- a/ewah/bitmap.c +++ b/ewah/bitmap.c @@ -129,30

[PATCH v2 1/7] ewah/bitmap.c: delete unused 'bitmap_clear()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/bitmap.c | 8 ewah/ewok.h | 1 - 2 files changed, 9 deletions(-) diff --git a/ewah/bitmap.c b/ewah/bitmap.c index 756bdd050e..d61dc6114a 100644 --- a/ewah/bitmap.c +++ b/ewah/bitmap.c @@ -45,14 +45,6 @@ void

[PATCH v2 4/7] ewah_bitmap: delete unused 'ewah_and_not()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/ewah_bitmap.c | 73 -- ewah/ewok.h| 5 2 files changed, 78 deletions(-) diff --git a/ewah/ewah_bitmap.c b/ewah/ewah_bitmap.c index 5a4d3a6eb6..559adde37c 100644 ---

[PATCH v2 6/7] ewah_bitmap: delete unused 'ewah_or()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/ewah_bitmap.c | 69 -- ewah/ewok.h| 5 2 files changed, 74 deletions(-) diff --git a/ewah/ewah_bitmap.c b/ewah/ewah_bitmap.c index 3fa3edf2a3..017c677f98 100644 ---

[PATCH v2 5/7] ewah_bitmap: delete unused 'ewah_not()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/ewah_bitmap.c | 19 --- ewah/ewok.h| 7 --- 2 files changed, 26 deletions(-) diff --git a/ewah/ewah_bitmap.c b/ewah/ewah_bitmap.c index 559adde37c..3fa3edf2a3 100644 --- a/ewah/ewah_bitmap.c +++

[PATCH v2 3/7] ewah_bitmap: delete unused 'ewah_and()'

Reported-by: Ramsay Jones Signed-off-by: Derrick Stolee --- ewah/ewah_bitmap.c | 68 -- ewah/ewok.h| 5 2 files changed, 73 deletions(-) diff --git a/ewah/ewah_bitmap.c b/ewah/ewah_bitmap.c index b9fdda1d3d..5a4d3a6eb6 100644 ---

[PATCH v2 0/7] Delete unused methods in EWAH bitmap

The EWAH bitmap code includes several logical operations that are important for a general-purpose bitmap library. However, Git only uses the XOR operation for storing deltas between reachability bitmaps. This means that we can delete the following unused methods: * ewah_and() * ewah_and_not() *

Re: [PATCH v6 1/2] blame: prevent error if range ends past end of file

Isabella Stephens writes: >> Don't t800[12]-*.sh need adjustment for this change, too? > > Apologies. I will make sure I've run the whole test suite against > my patches in future. I've sent through a 7th (and hopefully > final) version. > Thanks. Will queue and hopefully we can carry this

Re: [PATCH v2 0/7] Delete unused methods in EWAH bitmap

Derrick Stolee writes: > The EWAH bitmap code includes several logical operations that are > important for a general-purpose bitmap library. However, Git only > uses the XOR operation for storing deltas between reachability > bitmaps. This means that we can delete the following unused methods: >

Re: [PATCH 1/3] ewah_read_mmap: bounds-check mmap reads

Jeff King writes: > On Fri, Jun 15, 2018 at 07:10:28PM +0200, SZEDER Gábor wrote: > >> > I said "yuck" because the original does not work if there happen to >> > be more than (or for that matter, less than) one '.bitmap' file >> > there. But at least as long as there is one, it should work ;-)

Re: fatal: could not reset submodule index

> # Trying again with submodule.recurse > git config --global submodule.recurse true > git clone main clone4 cd clone4 > git checkout with-submodule > # Submodule is still not automatically updated (sub folder is empty) > # It seems like submodule.recurse does not affect git clone That is true;

Re: [PATCH] unpack-trees: do not fail reset because of unmerged skipped entry

Max Kirillov writes: > After modify/delete merge conflict happens in a file skipped by sparse > checkout, "git reset --merge", which implements the "--abort" actions, and > "git reset --hard" fail with message "Entry * not uptodate. Cannot update > sparse checkout." The reason is that the entry

Re: [PATCH 3/3] ewah: drop ewah_serialize_native function

Jeff King writes: > One thing that gave me pause on ripping out more code is that I have > some bitmap-related patches on my send-to-upstream list, and I wasn't > sure if they used any of this code. But I checked against your patches, > and no, this can all go (which makes sense -- my patches

Re: [PATCHv3 0/1] git-p4 unshelve

On 15 May 2018 at 11:01, Luke Diamand wrote: > This is a git-p4 unshelve command which detects when extra > changes are going to be included, and refuses to unhshelve. > > As in my earlier unshelve change, this uses git fast-import > to do the actual delta generation, but now checks to see > if

Re: [PATCH] Makefile: make NO_ICONV really mean "no iconv"

On Fri, Jun 15, 2018 at 2:58 AM Simon Ruderich wrote: > On Thu, Jun 14, 2018 at 10:25:03PM -0400, Eric Sunshine wrote: > > This patch is extra noisy due to the indentation change. Viewing it with > > "git diff -w" helps. An alternative to re-indenting would have been to > > "undefine

Re: [PATCH] Makefile: make NO_ICONV really mean "no iconv"

On Thu, Jun 14, 2018 at 9:25 PM, Eric Sunshine wrote: > The Makefile tweak NO_ICONV is meant to allow Git to be built without > iconv in case iconv is not installed or is otherwise dysfunctional. > However, NO_ICONV's disabling of iconv is incomplete and can incorrectly > allow "-liconv" to slip

Re: [PATCH] Makefile: make NO_ICONV really mean "no iconv"

On Fri, Jun 15, 2018 at 02:30:43AM -0400, Eric Sunshine wrote: > On Fri, Jun 15, 2018 at 12:20 AM Jeff King wrote: > > We have OLD_ICONV, too, which should probably do nothing if NO_ICONV is > > set. I think that works OK. We end up setting -DOLD_ICONV on the command > > line, but that's only

Re: [PATCH] Makefile: make NO_ICONV really mean "no iconv"

On Thu, Jun 14, 2018 at 10:25:03PM -0400, Eric Sunshine wrote: > The Makefile tweak NO_ICONV is meant to allow Git to be built without > iconv in case iconv is not installed or is otherwise dysfunctional. > However, NO_ICONV's disabling of iconv is incomplete and can incorrectly > allow "-liconv"

Re: [ANNOUNCE] Git v2.16.0-rc0

On Fri, Jun 15, 2018 at 01:13:21AM -0400, Jeff King wrote: > > The trouble is that GIT_SSH_VARIANT=simple is too... simple. You > > would like a variant that passes in [-p port] [-4] [-6] as well. We > > didn't implement that because we didn't have the attention of any > > wrapper writer who

Re: [RFC PATCH 4/4] t/lib-httpd: sort log based on timestamp to avoid occasional failure

On Thu, Jun 14, 2018 at 11:27:03AM -0700, Junio C Hamano wrote: > Jeff King writes: > > >> Another alternative is to simply accept that these tests are racy, and > >> that the resulting test failures are rare enough that it isn't worth > >> the complexity of the workaround, but

[PATCH v7 1/2] blame: prevent error if range ends past end of file

From: Isabella Stephens If the -L option is used to specify a line range in git blame, and the end of the range is past the end of the file, git will fail with a fatal error. This commit prevents such behavior - instead we display the blame for existing lines within the specified range. Tests

[PATCH v7 2/2] log: prevent error if line range ends past end of file

From: Isabella Stephens If the -L option is used to specify a line range in git log, and the end of the range is past the end of the file, git will fail with a fatal error. This commit prevents such behaviour - instead we perform the log for existing lines within the specified range. This

Re: [PATCH] Makefile: make NO_ICONV really mean "no iconv"

On Fri, Jun 15, 2018 at 12:20 AM Jeff King wrote: > We have OLD_ICONV, too, which should probably do nothing if NO_ICONV is > set. I think that works OK. We end up setting -DOLD_ICONV on the command > line, but that's only consider inside "#ifndef NO_ICONV" within the > code. Right, that was my

Re: [PATCH v6 1/2] blame: prevent error if range ends past end of file

> Don't t800[12]-*.sh need adjustment for this change, too? Apologies. I will make sure I've run the whole test suite against my patches in future. I've sent through a 7th (and hopefully final) version.

Re: [PATCH 1/3] ewah_read_mmap: bounds-check mmap reads

> diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh > index 423c0a475f..237ee6e5fc 100755 > --- a/t/t5310-pack-bitmaps.sh > +++ b/t/t5310-pack-bitmaps.sh > @@ -331,4 +331,17 @@ test_expect_success 'pack reuse respects --incremental' ' > git show-index actual && > test_cmp