Re: Deleting of the specified ref during the post-receive hook

[Joshua Jensen <jjensen@workspacewhiz.com>]

  ----- Original Message -----
From: Shawn O. Pearce
Date: 9/21/2010 8:50 AM
> Joshua Jensen<jjensen@workspacewhiz.com>  wrote:
>> My current line of thought has an auto-merging script that monitors the
>> refs/for/ namespace (similar to Gerrit) and then applies --no-ff merges
>> to the appropriate branch.  For instance, when the user pushes to
>> refs/for/master, the post-receive hook creates a secondary ref called
>> refs/for/master-SHA1-timestamp and then deletes the refs/for/master ref
>>
> FWIW, you don't need `` around the git update-ref calls, because you
> aren't using the output of the command as input to another command.
You are right.  I believe I was early on, and it just got copied and 
pasted around.
> No.  If there are two concurrent pushes occurring, the script may
> execute in parallel.
Okay, so what I'm doing is bad.  Got it.
> But you'll actually get something much worse.  receive-pack will
> create refs/for/master for the first user... and then might be put
> to sleep while another user's receive-pack starts.  That second
> user will see refs/for/master existing, and will fail their push
> because their concept of $newrev doesn't match what is currently
> at refs/for/master.  Then the first user wakes up, runs your
> post-receive, and the ref is cleared.
Yep, this is exactly what I was trying to avoid by deleting the ref.
> The better strategy would be to use an update hook that refuses to
> permit the creation of refs/for/master:
>
>    #!/bin/sh
>    ref=$1
>    old=$2
>    new=$3
>
>    case $ref in
>    refs/for/*)
>      timestamp=`date +%s`
>      git update-ref $ref-$new-$timestamp $new
>      echo "Created $ref-$new-$timestamp"
>      exit 1
>      ;;
>    *)
>      exit 0
>      ;;
>    esac
>
>
> By exit 1 here we refuse the push attempt, so receive-pack won't
> create refs/for/master, and another user pushing won't see that
> false failure.  However, unlike with Gerrit, every user is now going
> to receive a push failure message because the hook has appeared to
> reject the value, even though it accepted it.
Okay, I'll try this.  I can train people in the push failure, if 
necessary.  Thanks!

>> Before I go too much deeper down this path, am I way off base here?
> I'd have to ask why you are using gitolite and trying to abuse
> git-receive-pack to do something that Gerrit does out of the box...
>
Oh, how I would love to just leave it to Gerrit to handle this.  (I 
*really* like Gerrit.)  If you would like to just skip ahead, the actual 
question related to this email message is in the final paragraph.

We don't want to squash our topic branches before pushing them to 
Gerrit.  That means we end up with a range of 'n' number of commits in 
the Gerrit review screen.  Gerrit understands that commit 'n' is 
dependent on 'n-1' and so on, but unfortunately, it doesn't show them in 
a tree/group on the main page.  That's a minor gripe, but here is the 
major issue.

When I review Change 1, I can press a submit button, and Change 1 goes 
live right then.  Unfortunately, changes 2 through n were left behind.

If I review Change 1 through n and then press the Submit button on 
Change n and then on Change n-1 and then on Change n-2, Gerrit does the 
'right' thing (for us) and makes live the entire dependency chain at the 
same time.  Of course, I would prefer to just have a group Submit 
button, but that's another story.

This has come up on the mailing list a few times, and I even think there 
is an issue tracker item for it.

Let's ignore the review+submit portion of Gerrit now.  Can Gerrit be 
coaxed to take a refs/for/master and directly apply it to the master 
branch WITHOUT the review cycle?  If so, then I'm wasting my time trying 
to right a script.

Josh