From: William Baker
Update midx_repack to only display progress when
the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/midx.c b/midx.c
index 35bdc5f72c..b5f7f1c54a 100644
--- a/midx.c
+++ b/midx.c
@@ -1373,6
From: William Baker
Add progress to expire_midx_packs. Progress is
displayed when the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 12
1 file changed, 12 insertions(+)
diff --git a/midx.c b/midx.c
index 006f36b570..7157259ca2 100644
--- a/midx.c
+++ b
From: William Baker
Add progress to write_midx_file. Progress is displayed
when the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/midx.c b/midx.c
index f169a681dd..006f36b570
From: William Baker
Update verify_midx_file to only display progress when
the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/midx.c b/midx.c
index 7157259ca2..35bdc5f72c 100644
--- a
From: William Baker
Add the --[no-]progress option to git multi-pack-index.
Pass the MIDX_PROGRESS flag to the subcommand functions
when progress should be displayed by multi-pack-index.
The progress feature was added to 'verify' in 144d703
("multi-pack-index: report progress
From: William Baker
Add the MIDX_PROGRESS flag and update the
write|verify|expire|repack functions in midx.h
to accept a flags parameter. The MIDX_PROGRESS
flag indicates whether the caller of the function
would like progress information to be displayed.
This patch only changes the method
patch.
Thanks, William
William Baker (6):
midx: add MIDX_PROGRESS flag
midx: add progress to write_midx_file
midx: add progress to expire_midx_packs
midx: honor the MIDX_PROGRESS flag in verify_midx_file
midx: honor the MIDX_PROGRESS flag in midx_repack
multi-pack-index: add [--[no-]p
On 10/16/19 12:48 PM, William Baker wrote:>> I do not care too deeply either
way, but if you wrote it in one way,
>> how about completing the series without changing it in the middle,
>> and leave the clean-ups to a follow-up series (if needed)?
>
>
> That plan s
On 10/15/19 7:09 PM, Junio C Hamano wrote:
>> At this time there are no other MIDX_* flags and so there's always the option
>> to revisit the best way to handle multiple MIDX_* flags if/when additional
>> flags are added.
>
> I do not care too deeply either way, but if you wrote it in one way,
> h
From: William Baker
The comments for the staging/unstaging test did not accurately
describe the scenario being tested. It is not essential that
the test files being staged/unstaged appear at the end of the
index. All that is required is that the test files are not
flagged with
This patch series is based on the 'wb/fsmonitor-bitmap-fix' branch and
addresses feedback on the new test that was added there.
I've updated the comments for the new test to more accurately describe the
scenario being tested.
Thanks,
William
William Baker (1):
t7519-s
On 10/8/19 6:32 PM, SZEDER Gábor wrote:
>>> No, they tend to show (PROGRESS | REGRESS), at least both gdb and lldb
>>> do.
>
> I was wrong here, gdb does this, but lldb, unfortunately, doesn't; see
> my other reply in this thread.
>
>> What I was worried about is that the constants that are used t
On 10/11/19 6:26 PM, Junio C Hamano wrote:
> "William Baker via GitGitGadget" writes:
>
>> +# Test staging/unstaging files that appear at the end of the index. Test
>> +# file names begin with 'z' so that they are sorted to the end of the
>> index.
Dscho.
Thanks, William
William Baker (1):
fsmonitor: don't fill bitmap with entries to be removed
fsmonitor.c | 29 -
t/t7519-status-fsmonitor.sh | 17 +
t/t7519/fsmonitor-env | 24
3 files change
From: William Baker
While doing some testing with fsmonitor enabled I found
that git commands would segfault after staging and
unstaging an untracked file. Looking at the crash it
appeared that fsmonitor_ewah_callback was attempting to
adjust bits beyond the bounds of the index cache.
Digging
On 10/10/19 4:22 AM, SZEDER Gábor wrote:
>>> +# This test covers staging/unstaging files that appear at the end of the
>>> index.
>>> +# Test files with names beginning with 'z' are used under the assumption
>>> that
>>> +# earlier tests do not add/leave index entries that sort below them.
>
>
ment to be more descriptive
Thanks,
William
William Baker (1):
fsmonitor: don't fill bitmap with entries to be removed
fsmonitor.c | 29 -
t/t7519-status-fsmonitor.sh | 13 +
t/t7519/fsmonitor-env | 24 +
From: William Baker
While doing some testing with fsmonitor enabled I found
that git commands would segfault after staging and
unstaging an untracked file. Looking at the crash it
appeared that fsmonitor_ewah_callback was attempting to
adjust bits beyond the bounds of the index cache.
Digging
but I'd still wait for a few
> days for people who expressed their Acks but your scan missed, or
> those who wanted to give their Acks but forgot to do so, to raise
> their hands on this thread.
>
This looks good to me as well:
Acked-by: William Baker
Thanks,
William
On 10/7/19 9:30 PM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>>> func(PROGRESS | REGRESS);
>>> func(PROGRESS + REGRESS);
>>> func(PROGRESS * 3);
>>> }
>>>
>>> how caller came about to give 3?
>>
>> No, they tend to show (PROGRESS | REGRESS), at least
On 10/3/19 4:36 PM, Junio C Hamano wrote:
>> +if (pos >= istate->cache_nr)
>> +BUG("fsmonitor_dirty has more entries than the index
>> (%"PRIuMAX" >= %"PRIuMAX")",
>> +(uintmax_t)pos, (uintmax_t)istate->cache_nr);
>
> This is how we show size_t values without usin
From: William Baker
While doing some testing with fsmonitor enabled I found
that git commands would segfault after staging and
unstaging an untracked file. Looking at the crash it
appeared that fsmonitor_ewah_callback was attempting to
adjust bits beyond the bounds of the index cache.
Digging
some BUG checks that would have helped
catch this problem sooner. Special thanks to Dscho for pointing me in the
right direction and suggesting a test that can reproduce the issue.
Thanks, William
William Baker (1):
fsmonitor: don't fill bitmap with entries to be removed
f
From: William Baker
Add progress to write_midx_file. Progress is displayed
when the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/midx.c b/midx.c
index b2673f52e8..0808a40dd4
From: William Baker
Update midx_repack to only display progress when
the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/midx.c b/midx.c
index ced5898bbf..1c5ddeb007 100644
--- a/midx.c
+++ b/midx.c
@@ -1374,6
From: William Baker
Add the --[no-]progress option to git multi-pack-index.
Pass the MIDX_PROGRESS flag to the subcommand functions
when progress should be displayed by multi-pack-index.
The progress feature was added to 'verify' in 144d703
("multi-pack-index: report progress
From: William Baker
Add the MIDX_PROGRESS flag and update the
write|verify|expire|repack functions in midx.h
to accept a flags parameter. The MIDX_PROGRESS
flag indicates whether the caller of the function
would like progress information to be displayed.
This patch only changes the method
From: William Baker
Update verify_midx_file to only display progress when
the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/midx.c b/midx.c
index f14bebb092..ced5898bbf 100644
--- a
From: William Baker
Add progress to expire_midx_packs. Progress is
displayed when the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 12
1 file changed, 12 insertions(+)
diff --git a/midx.c b/midx.c
index 0808a40dd4..f14bebb092 100644
--- a/midx.c
+++ b
ed
Thanks, William
William Baker (6):
midx: add MIDX_PROGRESS flag
midx: add progress to write_midx_file
midx: add progress to expire_midx_packs
midx: honor the MIDX_PROGRESS flag in verify_midx_file
midx: honor the MIDX_PROGRESS flag in midx_repack
multi-pack-index: add [--[no-]progre
On 10/2/19 12:04 AM, Junio C Hamano wrote>>
>> Well, if you write
>>
>> enum { BIT_0 = 1, BIT_1 = 2, BIT_3 = 4 } var;
>>
>> it's pretty much a promise that the normal value for the var is one
>> of these listed values to your readers.
>
> ... that is why compilers give a warning when you writ
On 9/27/19 8:40 PM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>>> +#define MIDX_PROGRESS (1 << 0)
>>
>> Please consider using an enum.
>
> If they are used by assiging one of their values, definitely a good
> idea to use an enum. Are debuggers clever enough that they can
> tell, when t
On 9/27/19 8:49 PM, Junio C Hamano wrote:
diff --git a/midx.c b/midx.c
index b2673f52e8..54e4e93b2b 100644
--- a/midx.c
+++ b/midx.c
@@ -449,6 +449,8 @@ struct pack_list {
uint32_t nr;
uint32_t alloc;
struct multi_pack_index *m;
+ struct progre
On 9/21/19 5:11 AM, SZEDER Gábor wrote:
>>
>> +#define MIDX_PROGRESS (1 << 0)
>
> Please consider using an enum.
>
> A preprocessor constant is just that: a number. It is shown as a
> number while debugging, and there is no clear indication what related
> values belong in the same group (a
On 9/20/19 1:10 PM, Junio C Hamano wrote:
>> diff --git a/midx.c b/midx.c
>> index b2673f52e8..54e4e93b2b 100644
>> --- a/midx.c
>> +++ b/midx.c
>> @@ -449,6 +449,8 @@ struct pack_list {
>> uint32_t nr;
>> uint32_t alloc;
>> struct multi_pack_index *m;
>> +struct progress *progre
On 9/20/19 1:23 PM, Philip Oakley wrote:
> These subject lines are a bit long. Has there been some white space damage
> during preparation, such that the end of line, and following blank line, for
> a short subject line been compromised?
>
> Normally the 'git log --oneline' should fit within th
On 9/20/19 12:54 PM, Junio C Hamano wrote:
>
> Do all of these commits have overly long title with no body recorded
> in the commit objects, or is this just a mail sending program
> screwing up?
>
Sorry about that! With some help from Stolee I found the issue was that
I was missing a second lin
From: William Baker
Signed-off-by: William Baker
---
midx.c | 12
1 file changed, 12 insertions(+)
diff --git a/midx.c b/midx.c
index 54e4e93b2b..3a0e161aea 100644
--- a/midx.c
+++ b/midx.c
@@ -1206,18 +1206,29 @@ int expire_midx_packs(struct repository *r, const char
From: William Baker
Signed-off-by: William Baker
---
Documentation/git-multi-pack-index.txt | 6 ++-
builtin/multi-pack-index.c | 18 +--
t/t5319-multi-pack-index.sh| 69 ++
3 files changed, 87 insertions(+), 6 deletions(-)
diff --git a
From: William Baker
Signed-off-by: William Baker
---
midx.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/midx.c b/midx.c
index b2673f52e8..54e4e93b2b 100644
--- a/midx.c
+++ b/midx.c
@@ -449,6 +449,8 @@ struct pack_list {
uint32_t nr
From: William Baker
Signed-off-by: William Baker
---
midx.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/midx.c b/midx.c
index 3a0e161aea..dc7c5f43f8 100644
--- a/midx.c
+++ b/midx.c
@@ -1098,15 +1098,16 @@ int verify_midx_file(struct repository *r
Hello Git contributors!
My name is William Baker and I work at Microsoft. Over the past few years
I've worked closely with the Microsoft team contributing to the git
ecosystem and I'm excited to start working with the community.
Derrick Stolee helped me pick out my first task, and i
From: William Baker
Signed-off-by: William Baker
---
midx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/midx.c b/midx.c
index dc7c5f43f8..106ccc4ab2 100644
--- a/midx.c
+++ b/midx.c
@@ -1374,6 +1374,12 @@ int midx_repack(struct repository *r, const char
*object_dir, size_t
From: William Baker
Signed-off-by: William Baker
---
builtin/multi-pack-index.c | 8
builtin/repack.c | 2 +-
midx.c | 8
midx.h | 10 ++
4 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/builtin
On 9/13/19 1:26 PM, Junio C Hamano wrote:
> Compare the ways how dispatching and command line option parsing of
> subcommands in "multi-pack-index" and "commit-graph" are
> implemented. When a command (e.g. "commit-graph") takes common
> options and also has subcommands (e.g. "read" and "write")
Hi Junio,
Thanks for the review!
On 9/12/19 1:17 PM, Junio C Hamano wrote:
>> +'git multi-pack-index' [--object-dir=] [--[no-]progress]
>
> I am wondering what the reasoning behind having this new one *after*
> the subcommand while the existing one *before* is. Isn't the
> --[no-]progress opt
Hello Git contributors!
My name is William Baker and I work at Microsoft. Over the past few years
I've worked closely with the Microsoft team contributing to the git
ecosystem and I'm excited to start working with the community.
Derrick Stolee helped me pick out my first task, and i
From: William Baker
Signed-off-by: William Baker
---
Documentation/git-multi-pack-index.txt | 6 +-
builtin/multi-pack-index.c | 14 +---
midx.c | 30 +-
midx.h | 6 --
t/t5319
subscribe git
49 matches
Mail list logo
