Subject: Re: disallowing push to currently checked-out branch

From: Junio C Hamano <[email-masked]>
Date: Mon, 16 Feb 2009 13:43:03 -0800

Sergio Callegari <[email-masked]> writes:

> ... is there some case where one wants
> and has reasons to commit to a detached head before making a temporary
> branch on it?

Absolutely. I do it all the time for minor fix-ups after applying other's
patches on a newly created topic branch.

If you want a push to the current branch of _your_ repository detach HEAD
automatically and record which branch it was pointing at before you
detached, I am reasonably sure you can do that in post-receive hook, no?

I do not think it is such a bad thing to have a new value 'detach' to
receive.denyCurrentBranch as a possible non-default choice per-se, but the
earlier discussion Jeff pointed out is only showing that detaching alone
is not enough to help the user recover from the resulting state, and Dscho
discussed in this thread that detaching and recording the original branch
may not be enough either.  IOW, we do not know yet precisely what needs to
happen other than detaching HEAD when the configuration tells us to
'detach' to be useful.

So how about you experiment the workflow by setting the configuration to
'ignore', setting up a hook to detach _and do some other useful things_ as
necessary, and help all of us figuring out what other information is
useful to record when you receive such a push, and what new indications
you could give users to reduce the possibility of confusion?  Once we know
what we want to happen, we can have it as one of the canned choices and it
would help users.