If there's already a remote-helper tracking ref, we can fetch the SHA-1
to report proper push messages (as opposed to always reporting
[new branch]).

The remote-helper currently can specify the old SHA-1 to avoid this
problem, but there's no point in forcing all remote-helpers to be aware
of git commit ids; they should be able to be agnostic of them.

Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
Reviewed-by: Jeff King <p...@peff.net>
Signed-off-by: Junio C Hamano <gits...@pobox.com>

I already sent this, but it has had the unfortunate luck of getting stuck with
a bunch of irrelevant patches in 'next'.

This is not only good enough for 'master', but probably even 'maint'.

 t/t5801-remote-helpers.sh | 14 ++++++++++++++
 transport-helper.c        |  1 +
 2 files changed, 15 insertions(+)

diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index 69212cd..dbb02e2 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -186,4 +186,18 @@ test_expect_success GPG 'push signed tag with signed-tags 
capability' '
        compare_refs local signed-tag-2 server signed-tag-2
+test_expect_success 'push messages' '
+       (cd local &&
+       git checkout -b new_branch master &&
+       echo new >>file &&
+       git commit -a -m new &&
+       git push origin new_branch &&
+       git fetch origin &&
+       echo new >>file &&
+       git commit -a -m new &&
+       git push origin new_branch 2> msg &&
+       ! grep "\[new branch\]" msg
+       )
diff --git a/transport-helper.c b/transport-helper.c
index 5f8d075..835815f 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -806,6 +806,7 @@ static int push_refs_with_export(struct transport 
                if (private && !get_sha1(private, sha1)) {
                        strbuf_addf(&buf, "^%s", private);
                        string_list_append(&revlist_args, strbuf_detach(&buf, 
+                       hashcpy(ref->old_sha1, sha1);

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to