Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo

[Jeff King <peff@peff.net>]

On Tue, Nov 11, 2008 at 07:44:06PM -0500, Kyle Moffett wrote:

> Hmm, I wonder if it would be possible to also add a "detach" variant;
> which would create a detached-HEAD at the current commit when
> automatically receiving a push to the working branch.  I have a
> post-receive script that does so right now on a couple repositories.
> It's still a little confusing to someone actively working in the
> repository being pushed to, but it's much easier to explain than the
> current default behavior.

A neat idea, but I'm not sure what workflow that is meant to support.

Before you had:

  1. git push non-bare-remote theirHEAD
  2a. echo Oops, I've just screwed myself.
    3a. ssh remote 'git reset --soft HEAD@{1}'
  2b. echo Oops, I just screwed somebody else.
    3b. echo sorry | mail somebody.else

With "refuse" you have:

  1. git push non-bare-remote theirHEAD
  2. echo Oops, rejected.
  3. git push non-bare-remote theirHEAD:elsewhere
  4a. ssh remote 'git merge elsewhere'
  4b. echo 'please merge elsewhere' | mail somebody.else

which is an improvement. With "detach" you have:

  1. git push non-bare-remote theirHEAD
  2. echo Oh, now we've detached on the remote.
  3a. ssh remote 'git checkout theirHEAD'
  3b. echo 'please merge theirHEAD. BTW, you have been detached without
            realizing it, so make sure you didn't lose any commits.' |
            mail somebody.else

So I think in the case that you are working by yourself, you haven't
really saved much effort (you didn't have to repeat your push, but you
still have to go to the remote and checkout instead of merge). But if
you are pushing into somebody _else_'s repo, you have just mightily
confused them as they start to make commits on top of the detached HEAD.

Still, there may be some instances where moving to the detached HEAD is
preferable. But, like the "try to merge if we can" strategy, I think it
is better implemented by setting denyCurrentBranch to ignore and using a
hook for those instances. And if either hook becomes ubiquitous, maybe
it will be worth implementing within git itself (but I doubt it for
either, as the desired behavior is highly dependent on your personal
workflow).

-Peff