# [PATCH] Fix contrib/hooks/post-receive-email for new branch with no new commits 5 messages from 2009-02-10 to 2009-02-10. Participants: Pat Notz, Jakub Narebski, Johannes Schindelin, Junio C Hamano. Thread: https://gitlist.dev/t/17697 ## Pat Notz, 2009-02-10 13:48 Subject: [PATCH] Fix contrib/hooks/post-receive-email for new branch with no new commits Message-ID: <1234273695-4981-1-git-send-email-pknotz@sandia.gov> URL: https://gitlist.dev/e/1234273695-4981-1-git-send-email-pknotz%40sandia.gov ``` In the show_new_revisions function, the original code: git rev-parse --not --branches | grep -v $(git rev-parse $refname) | isn't quite right since one can create a new branch and push it without any new commits. In that case, two refs will have the same sha1 but both would get filtered by the 'grep'. In the end, we'll show ALL the history which is not what we want. Instead, we should list the branches by name and remove the branch being updated and THEN pass that list through rev-parse. Signed-off-by: Pat Notz --- contrib/hooks/post-receive-email | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email index 28a3c0e..116f89c 100644 --- a/contrib/hooks/post-receive-email +++ b/contrib/hooks/post-receive-email @@ -615,7 +615,9 @@ show_new_revisions() revspec=$oldrev..$newrev fi - git rev-parse --not --branches | grep -v $(git rev-parse $refname) | + this_branch=$(echo $refname | sed 's@refs/heads/@@') + other_branches=$(git branch | sed 's/\*//g' | grep -v $this_branch) + git rev-parse --not $other_branches | if [ -z "$custom_showrev" ] then git rev-list --pretty --stdin $revspec -- 1.6.1.2 ``` ## Jakub Narebski, 2009-02-10 15:46 Subject: Re: [PATCH] Fix contrib/hooks/post-receive-email for new branch with no new commits Message-ID: URL: https://gitlist.dev/e/m3ab8uuwfg.fsf%40localhost.localdomain In-Reply-To: <1234273695-4981-1-git-send-email-pknotz@sandia.gov> ``` "Pat Notz" writes: > In the show_new_revisions function, the original code: > > git rev-parse --not --branches | grep -v $(git rev-parse $refname) | > > isn't quite right since one can create a new branch and push it without > any new commits. In that case, two refs will have the same sha1 but > both would get filtered by the 'grep'. In the end, we'll show ALL the > history which is not what we want. Instead, we should list the branches > by name and remove the branch being updated and THEN pass that list > through rev-parse. Good idea, bad execution. > > Signed-off-by: Pat Notz > --- > contrib/hooks/post-receive-email | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email > index 28a3c0e..116f89c 100644 > --- a/contrib/hooks/post-receive-email > +++ b/contrib/hooks/post-receive-email > @@ -615,7 +615,9 @@ show_new_revisions() > revspec=$oldrev..$newrev > fi > > - git rev-parse --not --branches | grep -v $(git rev-parse $refname) | > + this_branch=$(echo $refname | sed 's@refs/heads/@@') > + other_branches=$(git branch | sed 's/\*//g' | grep -v $this_branch) git-branch is porcelain, git-branch is porcelain, git-branch is porcelain, git-branch is porcelain, git-branch is porcelain, git-branch is porcelain, git-branch is porcelain, git-branch is porcelain, ... Don't use sed if shell will suffice... Either: + this_branch=$refname + other_branches=$(git for-each-ref --format='%(refname)' refs/heads/ | + grep -v $this_branch) or + this_branch=${refname#refs/heads/} ... > + git rev-parse --not $other_branches | > if [ -z "$custom_showrev" ] > then > git rev-list --pretty --stdin $revspec > -- > 1.6.1.2 > > -- Jakub Narebski Poland ShadeHawk on #git ``` ## Johannes Schindelin, 2009-02-10 15:59 Subject: Re: [PATCH] Fix contrib/hooks/post-receive-email for new branch with no new commits Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0902101655500.10279%40pacific.mpi-cbg.de In-Reply-To: ``` Hi, On Tue, 10 Feb 2009, Jakub Narebski wrote: > "Pat Notz" writes: > > > In the show_new_revisions function, the original code: > > > > git rev-parse --not --branches | grep -v $(git rev-parse $refname) | > > > > isn't quite right since one can create a new branch and push it without > > any new commits. In that case, two refs will have the same sha1 but > > both would get filtered by the 'grep'. In the end, we'll show ALL the > > history which is not what we want. Instead, we should list the branches > > by name and remove the branch being updated and THEN pass that list > > through rev-parse. > > Good idea, bad execution. And I thought that I hold the patent for grumpy comments on this list :-) As for your suggestions, I think they are valid. We try to keep the interface of certain commands (so called "plumbing") stable, for script consumption. "git for-each-ref" is such a command. However, "git branch" is meant for human consumption, and a pretty recent patch wants to change the interface to make it even friendlier -- but breaking scripts' assumption in the process, should they use "git branch". Ciao, Dscho ``` ## Junio C Hamano, 2009-02-10 16:30 Subject: Re: [PATCH] Fix contrib/hooks/post-receive-email for new branch with no new commits Message-ID: <7vbptantj2.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vbptantj2.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Jakub Narebski writes: > + this_branch=$refname > + other_branches=$(git for-each-ref --format='%(refname)' refs/heads/ | > + grep -v $this_branch) This is still not quite right. grep -F -v "$this_branch" perhaps? ``` ## Pat Notz, 2009-02-10 16:43 Subject: [PATCH] Fix contrib/hooks/post-receive-email for new duplicate branch Message-ID: <1234284210-7122-1-git-send-email-pknotz@sandia.gov> URL: https://gitlist.dev/e/1234284210-7122-1-git-send-email-pknotz%40sandia.gov In-Reply-To: <7vbptantj2.fsf@gitster.siamese.dyndns.org> ``` In the show_new_revisions function, the original code: git rev-parse --not --branches | grep -v $(git rev-parse $refname) | isn't quite right since one can create a new branch and push it without any new commits. In that case, two refs will have the same sha1 but both would get filtered by the 'grep'. In the end, we'll show ALL the history which is not what we want. Instead, we should list the branches by name and remove the branch being updated and THEN pass that list through rev-parse. Revised as suggested by Jakub Narebski and Junio C Hamano to use git-for-each-ref instead of git-branch. (Thanks!) Signed-off-by: Pat Notz --- contrib/hooks/post-receive-email | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email index 28a3c0e..60cbab6 100644 --- a/contrib/hooks/post-receive-email +++ b/contrib/hooks/post-receive-email @@ -615,7 +615,9 @@ show_new_revisions() revspec=$oldrev..$newrev fi - git rev-parse --not --branches | grep -v $(git rev-parse $refname) | + other_branches=$(git for-each-ref --format='%(refname)' refs/heads/ | + grep -F -v $refname) + git rev-parse --not $other_branches | if [ -z "$custom_showrev" ] then git rev-list --pretty --stdin $revspec -- 1.6.1.2 ```