Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add `range-diff`, a `tbdiff` lookalike #1

Closed
wants to merge 21 commits into from

Conversation

Projects
None yet
2 participants
@dscho
Copy link
Member

commented Jun 5, 2018

The incredibly useful git-tbdiff tool to compare patch series (say, to see what changed between two iterations sent to the Git mailing list) is slightly less useful for this developer due to the fact that it requires the hungarian and numpy Python packages which are for some reason really hard to build in MSYS2. So hard that I even had to give up, because it was simply easier to re-implement the whole shebang as a builtin command.

The project at https://github.com/trast/tbdiff seems to be dormant, anyway. Funny (and true) story: I looked at the open Pull Requests to see how active that project is, only to find to my surprise that I had submitted one in August 2015, and that it was still unanswered let alone merged.

While at it, I forward-ported AEvar's patch to force --decorate=no because git -p tbdiff would fail otherwise.

Side note: I work on implementing range-diff not only to make life easier for reviewers who have to suffer through v2, v3, ... of my patch series, but also to verify my changes before submitting a new iteration. And also, maybe even more importantly, I plan to use it to verify my merging-rebases of Git for
Windows (for which I previously used to redirect the pre-rebase/post-rebase diffs vs upstream and then compare them using git diff --no-index). And of course any interested person can see what changes were necessary e.g. in the merging-rebase of Git for Windows onto v2.17.0 by running a command like:

        base=^{/Start.the.merging-rebase}
        tag=v2.17.0.windows.1
        pre=$tag$base^2
        git range-diff $pre$base..$pre $tag$base..$tag

The command uses what it calls the "dual color mode" (can be disabled via --no-dual-color) which helps identifying what actually changed: it prefixes lines with a - (and red background) that correspond to the first commit range, and with a + (and green background) that correspond to the second range. The rest of the lines will be colored according to the original diffs.

Changes since v4:

  • Fixed a typo in the commit message of "range-diff: add tests" that was introduced in v4.
  • White-space fixes.
  • Fixed the length of the first header underline in the man page.
  • Changed the preprocessor guard in linear-assignment.h to reflect the new name (instead of the old name, which was hungarian.h).
  • Likewise, changed the preprocessor guards in range-diff.h to hide the history of the thrice-renamed command.
  • Fixed indentation in the completion.
  • Instead of trying to paper over white-space error handling that does not apply to "diffs of diffs", dual color mode now simply disables all white-space warnings.
  • When showing the "single arg must be symmetric range" error message, git range-diff now also shows the usage.
  • Adjusted the commit message of "range-diff: adjust the output of the commit pairs" to avoid the surprise of the reviewer when onelines are printed all of a sudden, too.
  • "range-diff: adjust the output of the commit pairs" is now using a simpler way to print onelines.
  • We are now sandwiching the diff_opt_parse() loop between two parse_options(), to make sure that we caught all options, and that the -- separator is handled.
  • Adjusted the lookup_commit_reference() call to the newest master (it now takes a the_repository parameter).

Changes since v3:

  • The cover letter was adjusted to reflect the new reality (the command is called range-diff now, not branch-diff, and --dual-color is the default).
  • The documentation was adjusted a bit more in the patch that makes --dual-color the default.
  • Clarified the calculation of the cost matrix, as per Stefan Beller's request.
  • The man page now spells out that merge commits are ignored in the commit ranges (not merges per se).
  • The code in linear-assignment.c was adjusted to use the SWAP() macro.
  • The commit message of the patch introducing the first rudimentary implementation no longer talks about the "Hungarian" algorithm, but about the "linear assignment algorithm" instead.
  • A bogus indentation change was backed out from the patch introducing the first rudimentary implementation.
  • Instead of merely warning about missing .. in the 2-parameter invocation, we now exit with the error message.
  • The diff_opt_parse() function is allowed to return a value larger than 1, indicating that more than just one command-line parameter was parsed. We now advance by the indicated value instead of always advancing exactly 1 (which is still correct much of the time).
  • A lengthy if...else if...else if...else was simplified (from a logical point of view) by reordering it.
  • The unnecessarily static variable dashes was turned into a local variable of the caller.
  • The commit message talking about the new man page still referred to git branch --diff, which has been fixed.
  • A forgotten t7910 reference was changed to t3206.
  • An unbalanced double-tick was fixed in the man page.
  • Fixed grammar both of the commit message and the description of the --no-dual-color option.
  • To fix the build, a blank man page is now introduced together with the new range-diff command, even if it is populated for real only at a later patch (i.e. at the same time as before).
  • The headaches Junio fears would be incurred by that simple workaround to avoid bogus white-space error reporting are fended off: a more complex patch is now in place that adds (and uses) a new white-space flag. Sadly, as is all too common when Junio "encourages" me to replace a simple workaround by something "proper", it caused all kinds of headaches to get this right, so I am rather less certain that the "proper" fix will cause us less headaches than the simple workaround would have done. But whatever.
  • The dual color mode now also dims the changes that are exclusively in the first specified commit range, and uses bold face on the changes exclusively in the second one. This matches the intuition when using range-diff to compare an older iteration of a patch series to a newer one: the changes from the previous iteration that were replaced by new ones "fade", while the changes that replace them are "shiny new".

Changes since v2:

  • Right-aligned the patch numbers in the commit pairs.
  • Used ALLOC_ARRAY() in hungarian.c instead of xmalloc(sizeof()*size).
  • Changed compute_assignment()s return type from int to void, as it always succeeds.
  • Changed the Hungarian Algorithm to use an integer cost matrix.
  • Changed the --creation-weight option to --creation-factor where is an integer.
  • Retitled 1/19 and 2/19 to better conform with the current conventions, as pointed out (and suggested) by Junio.
  • Shut up Coverity, and at the same time avoided passing the unnecessary i and j parameters to output_pair_header().
  • Removed support for the --no-patches option: we inherit diff_options' support for -s already (and much more).
  • Removed the ugly _INV enum values, and introduced a beautiful GIT_COLOR_REVERSE instead. This way, whatever the user configured as color.diff.new (or .old) will be used in reverse in the dual color mode.
  • Instead of overriding the fragment header color, the dual color mode will now reverse the "outer" fragment headers, too.
  • Turned the stand-alone branch-diff command into the --diff option of git branch. Adjusted pretty much all commit messages to account for this. This change should no longer be visible: see below.
  • Pretty much re-wrote the completion, to support the new --diff mode of git-branch. See below: it was reverted for range-diff.
  • Renamed t7910 to t3206, to be closer to the git-branch tests.
  • Ensured that git_diff_ui_config() gets called, and therefore color.diff.* respected.
  • Avoided leaking four_spaces.
  • Fixed a declaration in a for (;;) statement (which Junio had as a fixup! that I almost missed).
  • Renamed branch --diff, which had been renamed from branch-diff (which was picked to avoid re-using tbdiff) to range-diff.
  • Renamed hungarian.c and its header to linear-assignment.c
  • Made --dual-color the default, and changed it to still auto-detect whether color should be used rather than forcing it

@gitgitgadget gitgitgadget deleted a comment from gitgitgadget bot Jun 5, 2018

@gitgitgadget

This comment has been minimized.

Copy link

commented Jun 7, 2018

An error occurred while submitting:

Error: Branch f8c4e30 is not rebased to upstream/master

@gitgitgadget gitgitgadget deleted a comment from gitgitgadget bot Jun 7, 2018

@gitgitgadget gitgitgadget deleted a comment from gitgitgadget bot Jun 7, 2018

@gitgitgadget gitgitgadget deleted a comment from gitgitgadget bot Jun 7, 2018

@gitgitgadget gitgitgadget deleted a comment from gitgitgadget bot Jun 7, 2018

@gitgitgadget gitgitgadget deleted a comment from gitgitgadget bot Jun 7, 2018

@gitgitgadget gitgitgadget deleted a comment from gitgitgadget bot Jun 7, 2018

@gitgitgadget gitgitgadget deleted a comment from gitgitgadget bot Jun 7, 2018

@dscho dscho force-pushed the dscho:branch-diff branch from f8c4e30 to 1304201 Jun 7, 2018

@gitgitgadget gitgitgadget deleted a comment from gitgitgadget bot Jun 8, 2018

@gitgitgadget gitgitgadget deleted a comment from gitgitgadget bot Jun 8, 2018

@gitgitgadget gitgitgadget deleted a comment from gitgitgadget bot Jun 8, 2018

dscho pushed a commit that referenced this pull request Jun 20, 2018

fetch: stop clobbering existing tags without --force
Change "fetch" to treat "+" in refspecs (aka --force) to mean we
should clobber a local tag of the same name.

This changes the long-standing behavior of "fetch" added in
853a369 ("[PATCH] Multi-head fetch.", 2005-08-20), before this
change all tag fetches effectively had --force enabled. The original
rationale in that change was:

    > Tags need not be pointing at commits so there is no way to
    > guarantee "fast-forward" anyway.

That comment and the rest of the history of "fetch" shows that the
"+" (--force) part of refpecs was only conceived for branch updates,
while tags have accepted any changes from upstream unconditionally and
clobbered the local tag object. Changing this behavior has been
discussed as early as 2011[1].

I the current behavior doesn't make sense, it easily results in local
tags accidentally being clobbered. Ideally we'd namespace our tags
per-remote, but as with my 97716d2 ("fetch: add a --prune-tags
option and fetch.pruneTags config", 2018-02-09) it's easier to work
around the current implementation than to fix the root cause, so this
implements suggestion #1 from [1], "fetch" now only clobbers the tag
if either "+" is provided as part of the refspec, or if "--force" is
provided on the command-line.

This also makes it nicely symmetrical with how "tag" itself
works. We'll now refuse to clobber any existing tags unless "--force"
is supplied, whether that clobbering would happen by clobbering a
local tag with "tag", or by fetching it from the remote with "fetch".

It's still not at all nicely symmetrical with how "git push" works, as
discussed in the updated pull-fetch-param.txt documentation, but this
change brings them more into line with one another. I don't think
there's any reason "fetch" couldn't fully converge with the behavior
used by "push", but that's a topic for another change.

One of the tests added in 31b808a ("clone --single: limit the fetch
refspec to fetched branch", 2012-09-20) is being changed to use
--force where a clone would clobber a tag. This changes nothing about
the existing behavior of the test.

1. https://public-inbox.org/git/20111123221658.GA22313@sigill.intra.peff.net/

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

@dscho dscho force-pushed the dscho:branch-diff branch 2 times, most recently from 79ce337 to 4a68b95 Jun 30, 2018

@dscho

This comment has been minimized.

Copy link
Member Author

commented Jul 3, 2018

/submit

@gitgitgadget

This comment has been minimized.

Copy link

commented Jul 3, 2018

An error occurred while submitting:

Error: git tag -F - -a pr-1/dscho/branch-diff-v3 4a68b95 failed: 128,
fatal: tag 'pr-1/dscho/branch-diff-v3' already exists

@dscho

This comment has been minimized.

Copy link
Member Author

commented Jul 3, 2018

/submit

@gitgitgadget

This comment has been minimized.

Copy link

commented Jul 3, 2018

@dscho dscho force-pushed the dscho:branch-diff branch 3 times, most recently from ebf3fea to d4e27c6 Jul 7, 2018

@dscho dscho force-pushed the dscho:branch-diff branch 4 times, most recently from 5a2cf0c to d8498fb Jul 17, 2018

@dscho

This comment has been minimized.

Copy link
Member Author

commented Jul 21, 2018

/submit

@gitgitgadget

This comment has been minimized.

Copy link

commented Jul 21, 2018

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

What's cooking (2018/06 gitgitgadget#1)
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

fcharlie pushed a commit to fcharlie/git that referenced this pull request Jan 9, 2019

@@ -870,6 +870,7 @@ LIB_OBJS += gpg-interface.o
LIB_OBJS += graph.o

This comment has been minimized.

Copy link
@gitgitgadget

gitgitgadget bot Mar 5, 2019

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> +		else if (!line.buf[0] || starts_with(line.buf, "index "))
> +			/*
> +			 * A completely blank (not ' \n', which is context)
> +			 * line is not valid in a diff.  We skip it

I noticed this while wondering how somebody could teach range-diff
to honor --notes=amlog while preparing the patches to be compared
[*1*], but this assumption goes against what POSIX.1 says these
days.

    It is implementation-defined whether an empty unaffected line is
    written as an empty line or a line containing a single <space> character.

cf. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/diff.html#tag_20_34_10_07

We need to insert ", as we disable user's diff.suppressBlankEmpty
settings" before ".  We skip it" (and if we get affected by the
setting, we need to fix it; it is not ultra-urgent, though).

[Footnote]

*1* ... which I do not have a good answer to, yet.  As discussed
earlier, the diffopt passed into the show_range_diff() machinery is
primarily meant for the final output (i.e. how the matching patches
from the two iterations are compared) and not about how the patches
to be compared are generated.  Worse, --notes=amlog (and possibly
other useful options) are parsed by "git log" side of the machinery,
not "git diff" side that populates diffopt.

dscho pushed a commit that referenced this pull request Mar 18, 2019

unpack-trees: fix oneway_merge accidentally carry over stage index
One-way merge is supposed to take stat info from the index and
everything else from the given tree. This implies stage 0 because trees
can't have non-zero stages. The add_entry(.., old, ...) call however
will keep stage index from the index.

This is normally not a problem if the entry from the index is
normal (stage #0). But if there is a conflict, we'll get stage #1 entry
as "old" and it gets recorded in the final index. Fix it by clearing
stage mask.

This bug probably comes from b5b4250 (git-read-tree: make one-way
merge also honor the "update" flag, 2005-06-07). Before this commit, we
may create the final ("dst") index entry from the one in index, but we
do clear CE_STAGEMASK.

I briefly checked two- and three-way merge functions. I think we don't
have the same problem in those.

Reported-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Mar 19, 2019

unpack-trees: fix oneway_merge accidentally carry over stage index
Phillip found out that 'git checkout -f <branch>' does not restore
conflict/unmerged files correctly. All tracked files should be taken
from <branch> and all non-zero stages removed. Most of this is true,
except that the final file could be in stage one instead of zero.

"checkout -f" (among other commands) does this with one-way merge, which
is supposed to take stat info from the index and everything else from
the given tree. The add_entry(.., old, ...) call in oneway_merge()
though will keep stage index from the index.

This is normally not a problem if the entry from the index is
normal (stage #0). But if there is a conflict, stage #0 does not exist
and we'll get stage #1 entry as "old" variable, which gets recorded in
the final index. Fix it by clearing stage mask.

This bug probably comes from b5b4250 (git-read-tree: make one-way
merge also honor the "update" flag, 2005-06-07). Before this commit, we
may create the final ("dst") index entry from the one in index, but we
do clear CE_STAGEMASK.

I briefly checked two- and three-way merge functions. I think we don't
have the same problem in those.

Reported-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Apr 10, 2019

unpack-trees: fix oneway_merge accidentally carry over stage index
Phillip found out that 'git checkout -f <branch>' does not restore
conflict/unmerged files correctly. All tracked files should be taken
from <branch> and all non-zero stages removed. Most of this is true,
except that the final file could be in stage one instead of zero.

"checkout -f" (among other commands) does this with one-way merge, which
is supposed to take stat info from the index and everything else from
the given tree. The add_entry(.., old, ...) call in oneway_merge()
though will keep stage index from the index.

This is normally not a problem if the entry from the index is
normal (stage #0). But if there is a conflict, stage #0 does not exist
and we'll get stage #1 entry as "old" variable, which gets recorded in
the final index. Fix it by clearing stage mask.

This bug probably comes from b5b4250 (git-read-tree: make one-way
merge also honor the "update" flag, 2005-06-07). Before this commit, we
may create the final ("dst") index entry from the one in index, but we
do clear CE_STAGEMASK.

I briefly checked two- and three-way merge functions. I think we don't
have the same problem in those.

Reported-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Jun 28, 2019

test-lib: introduce test_commit_bulk
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 helper to do so.

We'll use t5310 as a guinea pig, as it has three 10-commit loops. Here
are hyperfine results before and after:

  [before]
  Benchmark #1: ./t5310-pack-bitmaps.sh --root=/var/ram/git-tests
    Time (mean ± σ):      2.846 s ±  0.305 s    [User: 3.042 s, System: 0.919 s]
    Range (min … max):    2.250 s …  3.210 s    10 runs

  [after]
  Benchmark #1: ./t5310-pack-bitmaps.sh --root=/var/ram/git-tests
    Time (mean ± σ):      2.210 s ±  0.174 s    [User: 2.570 s, System: 0.604 s]
    Range (min … max):    1.999 s …  2.590 s    10 runs

So we're over 20% faster, while making the callers slightly shorter. We
added a lot more lines in test-lib-function.sh, of course, and the
helper is way more featureful than we need here. But my hope is that it
will be flexible enough to use in more places.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Jun 28, 2019

t3311: use test_commit_bulk
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
    Time (mean ± σ):      5.821 s ±  0.691 s    [User: 3.146 s, System: 2.782 s]
    Range (min … max):    4.783 s …  6.841 s    10 runs

to:

  Benchmark #1: ./t3311-notes-merge-fanout.sh --root=/var/ram/git-tests
    Time (mean ± σ):      1.743 s ±  0.116 s    [User: 1.144 s, System: 0.691 s]
    Range (min … max):    1.629 s …  1.994 s    10 runs

for an average speedup of over 70%.

Unfortunately we still have to run 300 instances of "git notes add",
since the point is to test the fanout that comes from adding notes one
by one.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Jun 28, 2019

t5702: use test_commit_bulk
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.927 s    10 runs

to:

  Benchmark #1: ./t5702-protocol-v2.sh --root=/var/ram/git-tests
    Time (mean ± σ):      3.956 s ±  0.242 s    [User: 1.775 s, System: 1.627 s]
    Range (min … max):    3.449 s …  4.239 s    10 runs

for an average savings of over 25%.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Jun 28, 2019

t5703: use test_commit_bulk
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.903 s …  2.401 s    10 runs

to:

  Benchmark #1: ./t5703-upload-pack-ref-in-want.sh --root=/var/ram/git-tests
    Time (mean ± σ):      1.440 s ±  0.114 s    [User: 737.7 ms, System: 615.4 ms]
    Range (min … max):    1.230 s …  1.604 s    10 runs

for an average savings of almost 33%.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Jun 28, 2019

t6200: use test_commit_bulk
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    10 runs

to:

  Benchmark #1: ./t6200-fmt-merge-msg.sh --root=/var/ram/git-tests
    Time (mean ± σ):      1.343 s ±  0.179 s    [User: 766.5 ms, System: 662.9 ms]
    Range (min … max):    1.032 s …  1.664 s    10 runs

for an average savings of over 30%.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Jul 1, 2019

test-lib: introduce test_commit_bulk
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 helper to do so.

We'll use t5310 as a guinea pig, as it has three 10-commit loops. Here
are hyperfine results before and after:

  [before]
  Benchmark #1: ./t5310-pack-bitmaps.sh --root=/var/ram/git-tests
    Time (mean ± σ):      2.846 s ±  0.305 s    [User: 3.042 s, System: 0.919 s]
    Range (min … max):    2.250 s …  3.210 s    10 runs

  [after]
  Benchmark #1: ./t5310-pack-bitmaps.sh --root=/var/ram/git-tests
    Time (mean ± σ):      2.210 s ±  0.174 s    [User: 2.570 s, System: 0.604 s]
    Range (min … max):    1.999 s …  2.590 s    10 runs

So we're over 20% faster, while making the callers slightly shorter. We
added a lot more lines in test-lib-function.sh, of course, and the
helper is way more featureful than we need here. But my hope is that it
will be flexible enough to use in more places.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Jul 1, 2019

t3311: use test_commit_bulk
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
    Time (mean ± σ):      5.821 s ±  0.691 s    [User: 3.146 s, System: 2.782 s]
    Range (min … max):    4.783 s …  6.841 s    10 runs

to:

  Benchmark #1: ./t3311-notes-merge-fanout.sh --root=/var/ram/git-tests
    Time (mean ± σ):      1.743 s ±  0.116 s    [User: 1.144 s, System: 0.691 s]
    Range (min … max):    1.629 s …  1.994 s    10 runs

for an average speedup of over 70%.

Unfortunately we still have to run 300 instances of "git notes add",
since the point is to test the fanout that comes from adding notes one
by one.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Jul 1, 2019

t5702: use test_commit_bulk
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.927 s    10 runs

to:

  Benchmark #1: ./t5702-protocol-v2.sh --root=/var/ram/git-tests
    Time (mean ± σ):      3.956 s ±  0.242 s    [User: 1.775 s, System: 1.627 s]
    Range (min … max):    3.449 s …  4.239 s    10 runs

for an average savings of over 25%.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Jul 1, 2019

t5703: use test_commit_bulk
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.903 s …  2.401 s    10 runs

to:

  Benchmark #1: ./t5703-upload-pack-ref-in-want.sh --root=/var/ram/git-tests
    Time (mean ± σ):      1.440 s ±  0.114 s    [User: 737.7 ms, System: 615.4 ms]
    Range (min … max):    1.230 s …  1.604 s    10 runs

for an average savings of almost 33%.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Jul 1, 2019

t6200: use test_commit_bulk
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    10 runs

to:

  Benchmark #1: ./t6200-fmt-merge-msg.sh --root=/var/ram/git-tests
    Time (mean ± σ):      1.343 s ±  0.179 s    [User: 766.5 ms, System: 662.9 ms]
    Range (min … max):    1.032 s …  1.664 s    10 runs

for an average savings of over 30%.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.