Re: [PATCH] Use diff* with --exit-code in git-am, git-rebase and git-merge-ours

From: Junio C Hamano <junkio@cox.net>
Date: Mar 25, 2007, 06:01 UTC
Message-ID: <7vwt15c150.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070325005613.GE11507@steel.home>

Alex Riesen <raa.lkml@gmail.com> 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.

Show 12 quoted lines

> 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.