On Fri, Jun 28, 2019 at 09:36:14PM -0400, Derrick Stolee wrote:
> > Still, if it's not too painful to add them in time-wise, it probably
> > makes sense for the coverage tests to be as exhaustive as possible.
>
> Unfortunately, even running the t9*.sh tests once (among the two runs:
> first with
Here's a re-roll of just the first patch of this series, since that was
the one that got all the comments (and the others are textually
independent).
The changes are:
- drop the leftover in_dir assignment
- replace ${indir:+} magic with defaulting indir=. (so we always pass
it to "-C"
On 6/28/2019 5:42 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>
>> +struct repo_settings {
>> +char core_commit_graph;
>> +char gc_write_commit_graph;
>> +};
>
> I do not see a particular reason to favor type "char" here. "char"
> is wider than e.g. "signed int :
On 6/28/2019 7:59 PM, Jeff King wrote:
> On Fri, Jun 28, 2019 at 08:23:49AM -0400, Derrick Stolee wrote:
>
>> On 6/28/2019 2:45 AM, Jeff King wrote:
>>> On Thu, Jun 27, 2019 at 01:35:17PM -0400, Derrick Stolee wrote:
>>>
> t/helper/test-example-decorate.c
> 0ebbcf70 29) one = lookup_unknow
On Fri, Jun 28, 2019 at 08:49:30PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > So here's a patch to do that. Writing the bulk commit function was a fun
> > exercise, and I found a couple other places to apply it, too, shaving
> > off ~7.5 seconds from my test runs. Not ground-breaking, but I think
>
On Fri, Jun 28, 2019 at 02:53:26PM +0200, Johannes Schindelin wrote:
> > > It would be nice if we had a "test_commits_bulk" that used fast-import
> > > to create larger numbers of commits.
> >
> > So here's a patch to do that.
>
> I like the direction, especially because it would make it super ea
On Fri, Jun 28, 2019 at 05:32:35PM -0400, Eric Sunshine wrote:
> > +# The message, filename, and contents strings are evaluated by the shell
> > inside
> > +# double-quotes, with $n set to the current commit number. So you can do:
> > +#
> > +# test_commit_bulk --filename=file --contents='modif
On Fri, Jun 28, 2019 at 07:46:02PM -0400, Eric Sunshine wrote:
> On Fri, Jun 28, 2019 at 7:04 PM SZEDER Gábor wrote:
> > On Fri, Jun 28, 2019 at 05:32:35PM -0400, Eric Sunshine wrote:
> > > On Fri, Jun 28, 2019 at 5:39 AM Jeff King wrote:
> > > > + in_dir=${indir:+-C "$indir"}
> > >
> > >
On Fri, Jun 28, 2019 at 08:44:38PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > +# Similar to test_commit, but efficiently create commits, each with a
> > +# unique number $n (from 1 to by default) in the commit message.
>
> Is it intentional not to follow test_commit's convention of creating a
>
On Fri, Jun 28, 2019 at 10:53:41AM -0700, Junio C Hamano wrote:
> > + in_dir=${indir:+-C "$indir"}
>
> I thought that this assignment to $in_dir would be unnecessary if we
> parsed -C directly into it, i.e.
Heh, sorry for the confusion. That in_dir is leftover cruft. I was
trying to see if I c
On Fri, Jun 28, 2019 at 08:35:28AM -0400, Derrick Stolee wrote:
> > + while test "$total" -gt 0
> > + do
> > + echo "commit $ref" &&
> > + printf 'author %s <%s> %s\n' \
> > + "$GIT_AUTHOR_NAME" \
> > +
On Fri, Jun 28, 2019 at 08:23:49AM -0400, Derrick Stolee wrote:
> On 6/28/2019 2:45 AM, Jeff King wrote:
> > On Thu, Jun 27, 2019 at 01:35:17PM -0400, Derrick Stolee wrote:
> >
> >>> t/helper/test-example-decorate.c
> >>> 0ebbcf70 29) one = lookup_unknown_object(&one_oid);
> >>> 0ebbcf70 30) two
On Fri, Jun 28, 2019 at 04:18:37PM +, Vanak, Ibrahim wrote:
> But HPUX Dev team have seen one significance difference, when they
> were triaging this issue, the ways GIT operations handled by 2 OSs: On
> linux, around 40 processes are spawned for handling a GIT operation
> whereas on HPUX only
Hi, original reporter of the issue here. Some thoughts from a user perspective,
from outside the black box of “the machinery":
It seems unintuitive that including a command to execute between each rebase
merge implies an interactive rebase. It’s no more interactive than a sequence
of rebase me
On Fri, Jun 28, 2019 at 7:04 PM SZEDER Gábor wrote:
> On Fri, Jun 28, 2019 at 05:32:35PM -0400, Eric Sunshine wrote:
> > On Fri, Jun 28, 2019 at 5:39 AM Jeff King wrote:
> > > + in_dir=${indir:+-C "$indir"}
> >
> > Doesn't this suffer the problem in which some older/broken
> > shells[1][2][
On Fri, Jun 28, 2019 at 05:32:35PM -0400, Eric Sunshine wrote:
> On Fri, Jun 28, 2019 at 5:39 AM Jeff King wrote:
> > +# to have every commit touch the same file, but with unique content.
> > Spaces are
> > +# OK, but you must escape any metacharacters (like backslashes or
> > +# double-quotes)
This test uses several index hashes, which necessarily depend on the
version of the index and the hash algorithm in use. Use test_oid_cache
to provide values for these for both SHA-1 and SHA-256. Also, compute
an object ID and use $EMPTY_BLOB to make the remainder of the tests
independent of the
Update this test to use test_oid_cache to specify the object IDs for
both SHA-1 and SHA-256. Since this test now works with both algorithms,
remove the SHA1 prerequisite.
Signed-off-by: brian m. carlson
---
t/t1007-hash-object.sh | 58 +++---
1 file changed,
In order to make this test work with multiple hash algorithms, compute
the object ID used in this test instead of hard-coding it.
Signed-off-by: brian m. carlson
---
t/t2203-add-intent.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t2203-add-intent.sh b/t/t2203-ad
One assertion of this test checks for a shrinking cache tree. The
initial index contains a cache tree with two directory names but no
object ID, and the second index contains a cache tree with an object ID
but no directory name.
With SHA-1, the second index is smaller than the first, because the
Several parts of this test generate files that have specific hard-coded
object IDs in them. We don't really care about what the object ID in
question is, so we turn them all to zeros.
However, because some of these values are fixed and some are generated,
they can be of different lengths, which c
Compute several object ID values instead of hard-coding them, and use
test_oid_to_path to cleanly produce a path for an object.
Note that the bisect code which is tested here remains sensitive to the
hash algorithm in use because it uses the object ID to disambiguate
between two equidistant commit
Instead of parsing object IDs using fixed-length shell patterns, use cut
to extract the first two characters of an object ID in addition to the
test helper for object paths. Update another test to look up an
appropriate object ID fragment from the all-zeros object ID instead of
hardcoding the valu
There are several places in our testsuite where we want to insert a
slash after an object ID to make it into a path we can reference under
.git/objects, and we have various ways of doing so. Add a helper to
provide a standard way of doing this that works for all size hashes.
Signed-off-by: brian
Replace several hard-coded full and partial object IDs with variables or
computed values. Create junk data to stuff inside an invalid tree that
can be either 20 or 32 bytes long. Compute a binary all-zeros object ID
instead of hard-coding a 20-byte length.
Additionally, compute various object ID
This test uses a stub of a very large (64 GB) object to test our
generation of tar archives. In doing so, it uses the object ID of the
object so it can insert it into the database properly. Look up these
values using test_oid. Restructure the test slightly to use
test_oid_in_path.
Since we care
This is an additional series of fixes for tests to make them work with
SHA-256.
This series makes use of several constants, such as $ZERO_OID, which
will be replaced with appropriate values based on "test_oid" with later
work.
Changes from v2:
* Switch to using shell instead of sed in test_oid_to
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.
The third batch of topics post 2.2
Phillip Wood writes:
>>> I wonder if users understand that '-x' is "an interctive rebase".
>>> The documentation can read both ways, and one of these may want to
>>> be clarified.
>>>
>>> -x , --exec
>>> ...
>>> This uses the --interactive machinery internally, but it can
>>> be
"Derrick Stolee via GitGitGadget" writes:
> @@ -41,7 +42,6 @@ static int aggressive_depth = 50;
> static int aggressive_window = 250;
> static int gc_auto_threshold = 6700;
> static int gc_auto_pack_limit = 50;
> -static int gc_write_commit_graph;
> static int detach_auto = 1;
> static times
On Fri, Jun 28, 2019 at 5:39 AM Jeff King wrote:
> [...]
> For bulk creation, we can do much better by using fast-import, but it's
> often a pain to generate the input. Let's provide a helper to do so.
> [...]
> Signed-off-by: Jeff King
> ---
> diff --git a/t/test-lib-functions.sh b/t/test-lib-fu
On 6/28/2019 4:50 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>
>> +core.featureAdoptionRate::
>> +Set an integer value on a scale from 0 to 10 describing your
>> +desire to adopt new performance features. Defaults to 0. As
>> +the value increases, features a
On Fri, Jun 28, 2019 at 11:03 AM garrett dean wrote:
> I have been trying to install for on my PC for Windows ten and at
> first I was having a hang when it reached the end. Now pop ups are
> appearing saying there are configuration problems.
You'll likely get more helpful responses by contacting
"Derrick Stolee via GitGitGadget" writes:
> +core.featureAdoptionRate::
> + Set an integer value on a scale from 0 to 10 describing your
> + desire to adopt new performance features. Defaults to 0. As
> + the value increases, features are enabled by changing the
> + default values
On 06/26, Junio C Hamano wrote:
> * ra/cherry-pick-revert-skip (2019-06-24) 6 commits
> - cherry-pick/revert: advise using --skip
> - cherry-pick/revert: add --skip option
> - sequencer: use argv_array in reset_merge
> - sequencer: rename reset_for_rollback to reset_merge
> - sequencer: add ad
On Fri, Jun 28 2019, Jeff King wrote:
> On Fri, Jun 28, 2019 at 02:41:03AM -0400, Jeff King wrote:
>
>> I think this would exercise it, at the cost of making the test more
>> expensive:
>>
>> diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
>> index 82d7f7f6a5..8ed6982dcb 100755
>>
On Fri, Jun 28 2019, Jeff King wrote:
> Some tests need to create a string of commits. Doing this with
> test_commit is very heavy-weight, as it needs at least one process per
> commit (and in fact, uses several).
>
> For bulk creation, we can do much better by using fast-import, but it's
> ofte
Derrick Stolee writes:
> way to do this loop. The top thing on my mind are the 'eval "echo X"'
> lines. If they start processes, then we can improve the performance.
> If not, then it may not be worth it.
Sigh.
Do you mean 'echo' run inside 'eval' is one extra process? In most
modern shells,
Jeff King writes:
> +# The message, filename, and contents strings are evaluated by the shell
> inside
> +# double-quotes, with $n set to the current commit number. So you can do:
> +#
> +# test_commit_bulk --filename=file --contents='modification $n'
> +#
> +# to have every commit touch the s
> This applies suggestions made by Jonathan Tan, as well as fixes a
> Coccinelle-breaking error in strbuf usage, and makes an additional string
> localizable.
>
> Thanks,
>
> Matthew DeVore (10):
> list-objects-filter: encapsulate filter components
> list-objects-filter: put omits set in filt
Jeff King writes:
> When we receive a remote ref update to sha1 "X", we want to check that
> we have all of the objects needed by "X". We can assume that our
> repository is not currently corrupted, and therefore if we have a ref
> pointing at "Y", we have all of its objects. So we can stop our
>
Hello ALL,
I did try GIT_TRACE* environment variables but couldn't isolate the problem.
But HPUX Dev team have seen one significance difference, when they were
triaging this issue, the ways GIT operations handled by 2 OSs: On linux, around
40 processes are spawned for handling a GIT operation
Nguyễn Thái Ngọc Duy writes:
> t7814 has repo tree like this
>
> initial-repo
> submodule
> sub
>
> In each repo 'submodule' and 'sub', a commit is made to add the same
> initial file 'a' with the same message 'add a'. If tests run fast
> enough, the two commits are made in the same
Ævar Arnfjörð Bjarmason writes:
> Junio. I thought I'd submit this in before your merge to "next", but I
> see that happened. Are you OK with rewinding it for this (& maybe
> something else) or should I submit a v3 rebased on "next"?
Sensible choices are between
(1) reverting 984c7ccbbf (Merge
Matthew DeVore writes:
> This applies suggestions made by Jonathan Tan, as well as fixes a
> Coccinelle-breaking error in strbuf usage, and makes an additional string
> localizable.
OK, so the convention is that errbuf has already translated string,
so the call to die() made in a fairly high poi
Hello,
I have been trying to install for on my PC for Windows ten and at first I was
having a hang when it reached the end. Now pop ups are appearing saying there
are configuration problems.
On Fri, Jun 28, 2019 at 9:50 AM Johannes Schindelin
wrote:
>
> Hi Matheus,
>
> On Thu, 27 Jun 2019, Matheus Tavares Bernardino wrote:
>
> > On Thu, Jun 27, 2019 at 3:47 PM Johannes Schindelin
> > wrote:
> > >
> > > On Thu, 27 Jun 2019, Matheus Tavares Bernardino wrote:
> > >
> > > > On Wed, Jun 2
Hi Junio and Dscho
On 28/06/2019 12:49, Johannes Schindelin wrote:
Hi Junio,
On Thu, 27 Jun 2019, Junio C Hamano wrote:
"Johannes Schindelin via GitGitGadget"
writes:
- if (options.reschedule_failed_exec && !is_interactive(&options))
+ if (reschedule_failed_exec > 0 && !is_inte
On Thu, Jun 27, 2019 at 7:35 PM Derrick Stolee wrote:
>
> Here are some interesting sections I found when examining the test coverage
> report. I am only highlighting these sections because they seem to include
> non-trivial logic. In some cases, maybe the code isn't needed.
>
> On 6/27/2019 1:05
Assalamu Alaikum Wa Rahmatullahi Wa Barakatuh,
hello dear
I came across your contact during my private search. Mrs Aisha Al-
Qaddafi is my name, the only daughter of late Libyan president, am a
single Mother and a Widow with three Children.I have funds the sum of
$27.5 million USD for, investme
Assalamu Alaikum Wa Rahmatullahi Wa Barakatuh,
hello dear
I came across your contact during my private search. Mrs Aisha Al-
Qaddafi is my name, the only daughter of late Libyan president, am a
single Mother and a Widow with three Children.I have funds the sum of
$27.5 million USD for, investme
Hi Peff,
On Fri, 28 Jun 2019, Jeff King wrote:
> On Fri, Jun 28, 2019 at 02:41:03AM -0400, Jeff King wrote:
>
> > It would be nice if we had a "test_commits_bulk" that used fast-import
> > to create larger numbers of commits.
>
> So here's a patch to do that.
I like the direction, especially bec
Hi Matheus,
On Thu, 27 Jun 2019, Matheus Tavares Bernardino wrote:
> On Thu, Jun 27, 2019 at 3:47 PM Johannes Schindelin
> wrote:
> >
> > On Thu, 27 Jun 2019, Matheus Tavares Bernardino wrote:
> >
> > > On Wed, Jun 26, 2019 at 3:04 PM Junio C Hamano wrote:
> > > >
> > > > Johannes Schindelin w
On 6/28/2019 6:11 AM, Jeff King wrote:
> When we receive a remote ref update to sha1 "X", we want to check that
> we have all of the objects needed by "X". We can assume that our
> repository is not currently corrupted, and therefore if we have a ref
> pointing at "Y", we have all of its objects. S
Hi Duy,
On Thu, 27 Jun 2019, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
This commit is _awfully_ short given that...
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 580fd38f41..560051784e 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -458,7 +458,
On 6/28/2019 5:47 AM, Duy Nguyen wrote:
> On Fri, Jun 28, 2019 at 12:35 AM Derrick Stolee wrote:
>>> dir.c
>>> 3b2385cf 2840) static void jw_object_untracked_cache_dir(struct json_writer
>>> *jw,
>>> 3b2385cf 2845) jw_object_bool(jw, "valid", ucd->valid);
>>> 3b2385cf 2846) jw_object_bool(jw, "ch
On 6/28/2019 5:39 AM, Jeff King wrote:
> Some tests need to create a string of commits. Doing this with
> test_commit is very heavy-weight, as it needs at least one process per
> commit (and in fact, uses several).
>
> For bulk creation, we can do much better by using fast-import, but it's
> often
Hi everyone,
The 52nd edition of Git Rev News is now published:
https://git.github.io/rev_news/2019/06/28/edition-52/
Thanks a lot to Jeff Hostetler, David Pursehouse and Johannes
Schindelin who contributed this month!
Enjoy,
Christian, Jakub, Markus and Gabriel.
On 6/28/2019 2:45 AM, Jeff King wrote:
> On Thu, Jun 27, 2019 at 01:35:17PM -0400, Derrick Stolee wrote:
>
>>> t/helper/test-example-decorate.c
>>> 0ebbcf70 29) one = lookup_unknown_object(&one_oid);
>>> 0ebbcf70 30) two = lookup_unknown_object(&two_oid);
>>> 0ebbcf70 59) three = lookup_unknown_ob
Hi,
On Thu, 27 Jun 2019, Junio C Hamano wrote:
> "Quentin Nerden via GitGitGadget" writes:
>
> > From: Quentin Nerden
> >
> > To make the doc of git-clone easier to read,
> > refer to the long version of the options
> > (it is easier to guess what --verbose is doing than -v).
> >
> > Also:
> >
Hi Junio,
On Thu, 27 Jun 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > It does not make sense to stop non-interactive rebases when that config
> > setting is set to `true`.
>
> The reader is assumed to know that that confi
Hi Junio,
On Thu, 27 Jun 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> > > If we would not have plenty of exercise for the PCRE2 build
> >> > > options, I would be worried. But AFAICT the CI build includes
> >> > > this all the time, so we're fine.
> >> >
> >> > Well, I'd feel
On Fri, Jun 28, 2019 at 11:03:27AM +0100, Phillip Wood wrote:
> > I considered that, too, but I think it is safe. stdio has its own
> > locking, so every individual call is atomic. The potentially problematic
> > case would be where we switch back from line buffering to no-buffering,
> > and someb
On Fri, Jun 28, 2019 at 06:11:31AM -0400, Jeff King wrote:
> Subject: [PATCH] check_everything_connected: assume alternate ref tips...
Heh. This subject should just be "check_connected" these days. I wrote
this patch originally many years ago, before 7043c7071c
(check_everything_connected: use a
When we receive a remote ref update to sha1 "X", we want to check that
we have all of the objects needed by "X". We can assume that our
repository is not currently corrupted, and therefore if we have a ref
pointing at "Y", we have all of its objects. So we can stop our
traversal from "X" as soon as
Dear Peff and Dscho
On 27/06/2019 22:10, Jeff King wrote:
> On Thu, Jun 27, 2019 at 02:00:54PM +0200, Johannes Schindelin wrote:
>
>>> We can use setvbuf() to toggle buffering back and forth, but I'm not
>>> sure if there's a way to query the current buffering scheme for a stdio
>>> stream.
>>
>>
Hello everybody,
since last updates, git p4 does not work anymore:
# git p4 sync --verbose
Reading pipe: ['git', '--git-dir',
'/mnt/data/userspace/project-pb/MM6.test/.git', 'rev-parse', '--git-dir']
Reading pipe: git rev-parse --git-dir
Reading pipe: git rev-parse --show-cdup
Reading pipe: ['gi
On Fri, Jun 28, 2019 at 12:35 AM Derrick Stolee wrote:
> > dir.c
> > 3b2385cf 2840) static void jw_object_untracked_cache_dir(struct json_writer
> > *jw,
> > 3b2385cf 2845) jw_object_bool(jw, "valid", ucd->valid);
> > 3b2385cf 2846) jw_object_bool(jw, "check-only", ucd->check_only);
> > 3b2385cf
There's a loop that creates 30 commits using test_commit. Using
test_commit_bulk speeds this up from:
Benchmark #1: ./t6200-fmt-merge-msg.sh --root=/var/ram/git-tests
Time (mean ± σ): 1.926 s ± 0.240 s[User: 1.055 s, System: 0.963 s]
Range (min … max):1.431 s … 2.166 s
There are two loops that create 32 commits each using test_commit. Using
test_commit_bulk speeds this up from:
Benchmark #1: ./t5702-protocol-v2.sh --root=/var/ram/git-tests
Time (mean ± σ): 5.409 s ± 0.513 s[User: 2.382 s, System: 2.466 s]
Range (min … max):4.633 s … 5.92
There are two loops that create 33 commits each using test_commit. Using
test_commit_bulk speeds this up from:
Benchmark #1: ./t5703-upload-pack-ref-in-want.sh --root=/var/ram/git-tests
Time (mean ± σ): 2.142 s ± 0.161 s[User: 1.136 s, System: 0.974 s]
Range (min … max):1.9
One of the tests in t3311 creates 300 commits by running "test_commit"
in a loop. This requires 900 processes. Instead, we can use
test_commit_bulk to do it with only four. This improves the runtime of
the script from:
Benchmark #1: ./t3311-notes-merge-fanout.sh --root=/var/ram/git-tests
Tim
The bitmap index we compute in t5310 has only 20 commits in it. This
gives poor coverage of bitmap_writer_select_commits(), which simply
writes a bitmap for everything when there are fewer than 100 commits.
Let's bump the number of commits in the test to cover the more complex
code paths (this doe
Some tests need to create a string of commits. Doing this with
test_commit is very heavy-weight, as it needs at least one process per
commit (and in fact, uses several).
For bulk creation, we can do much better by using fast-import, but it's
often a pain to generate the input. Let's provide a help
On Fri, Jun 28, 2019 at 02:41:03AM -0400, Jeff King wrote:
> I think this would exercise it, at the cost of making the test more
> expensive:
>
> diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
> index 82d7f7f6a5..8ed6982dcb 100755
> --- a/t/t5310-pack-bitmaps.sh
> +++ b/t/t5310-pa
t7814 has repo tree like this
initial-repo
submodule
sub
In each repo 'submodule' and 'sub', a commit is made to add the same
initial file 'a' with the same message 'add a'. If tests run fast
enough, the two commits are made in the same second, resulting
identical commits.
There is n
On Fri, Jun 28 2019, Ævar Arnfjörð Bjarmason wrote:
> A non-RFC since it seem people like this approach.
>
> This should fix the test failure noted by Johannes, there's two new
> patches at the start of this series. They address a bug that was there
> for a long time, but I happened to trip over
On Fri, Jun 28 2019, Eric Wong wrote:
> Jeff King wrote:
>> On Sun, Jun 23, 2019 at 06:08:25PM +, Eric Wong wrote:
>>
>> > > I'm not sure of the right solution. For maximal backwards-compatibility,
>> > > the default for bitmaps could become "if not bare and if there are no
>> > > .keep fil
Jeff King wrote:
> On Sun, Jun 23, 2019 at 06:08:25PM +, Eric Wong wrote:
>
> > > I'm not sure of the right solution. For maximal backwards-compatibility,
> > > the default for bitmaps could become "if not bare and if there are no
> > > .keep files". But that would mean bitmaps sometimes not
79 matches
Mail list logo
