Alex Riesen <raa.lkml@xxxxxxxxx> writes:
> This simplifies the shell code, reduces its memory footprint, and
> speeds things up. The performance improvements should be noticable
> when git-rebase works on big commits.
Thanks.
Unlike some optimizations that tilts the tradeoffs to favor
often-used case by penalizing the less often-used case, this
change does not penalize any case while optimizing some cases,
so there is nothing we are losing. I'll take the patch for this
reason.
However, I have a few comments.
Have you run any benchmark? I suspect "and speeds things up" is
a gross overstatement. A qualified "SOMETIMES speeds things up"
would be a more honest thing to say.
Both of the changes to git-am are definitely good. Under normal
usage, we expect that we would see some diff, and the optimization
applies to that normal case.
> diff --git a/git-merge-ours.sh b/git-merge-ours.sh
> index 4f3d053..2b6a5c0 100755
> --- a/git-merge-ours.sh
> +++ b/git-merge-ours.sh
> @@ -9,6 +9,6 @@
> # because the current index is what we will be committing as the
> # merge result.
>
> -test "$(git-diff-index --cached --name-status HEAD)" = "" || exit 2
> +git-diff-index --quiet --cached HEAD || exit 2
>
> exit 0
I think this does not change the performance profile in the real
life. When the user uses the command correctly, we expect that
index and HEAD to match, and in that case the diff would take
the same amount of processing with or without --quiet. The
change does not penalize the opposite case, so it is not a wrong
thing to do, but this is an optimization to error out early.
The first change to git-rebase optimizes the case to handle
"still to be adopted upstream" case ("upstream swallowed our
change" case would perform the same as before), so the
optimization would be more visible by people with slower
upstream and/or people patches of lessor quality that are
rejected by upstream often. In other words, the amount of
speeding up by this change really depends on the user (there is
no slowdown for anybody so that is Ok).
The other optimizes the "erroring out early" uninteresting case.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html