Sergio Callegari <sergio.callegari@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
