For generating the diffstat after a branch update, git-diff-tree is
simply comparing the new revision with the base revision. However, the
baserev was being passed with a "^" operator proceeding it - this (I
think) made git-diff-tree think that a path was being specified for
comparison rather than a second path, so only a single revision was
Signed-off-by: Andy Parkins <firstname.lastname@example.org>
templates/hooks--update | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/templates/hooks--update b/templates/hooks--update
index 7e8258a..ee3859c 100644
@@ -193,8 +193,8 @@ case "$refname_type" in
git-rev-parse --not --all | git-rev-list --stdin --pretty $newrev ^$baserev
- echo "Diffstat:"
- git-diff-tree --no-color --stat -M -C --find-copies-harder $newrev ^$baserev
+ echo "Diffstat against $baserev:"
+ git-diff-tree --no-color --stat -M -C --find-copies-harder $newrev $baserev
This is wrong.
is right. The "not baserev" tells diff-tree that the baserev is the
starting point, so newrev is obviously the target, and thus that will
generate a diff from baserev to newrev.
So will either of
which mean _exactly_ the same thing as "newrev ^basrev" to "diff-tree",
because in all cases it's obviously "baserev" that is the old one to diff
means the diff from "new" to "base", which is exactly the wrong way
Of course, since we did
baserev=$(git-merge-base $oldrev $newrev)
to generate base-rev, we could actually have done
(note the _three_ dots) which means "diff from merge-base to newrev". But
since we use "baserev" multiple times, what the update hook does right now
is actually better - it avoids the cost of re-computing the merge base
that we needed for other things anyway.
Right. It's all come back to me now you've explained it; I obviously
understood it when I wrote it, but it leaked out in the interim :-). I
was surprised because I've been using the hook for ages and the output
seemed right. :-)
Junio - please ignore this patch.
Dr Andrew Parkins, M Eng (Hons), AMIEE