Re: [PATCH 1/2] Add a few more values for receive.denyCurrentBranch

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> I do not think of a good justification of detachInstead offhand, but
> >> you must have thought things through a lot more than I did, so you
> >> can come up with a work flow description that is more usable by mere
> >> mortals to justify that mode.
> >
> > The main justification is that it is safer than updateInstead because
> > it is guaranteed not to modify the working directory. I intended it
> > for use by developers who are uncomfortable with updating the working
> > directory through a push, and as uncomfortable with forgetting about
> > temporary branches pushed, say, via "git push other-computer
> > HEAD:refs/heads/tmp".
> >
> > However, I have to admit that I never used this myself after the first
> > few weeks of playing with this patch series.
> >
> >> Without such a description to justify why detachInstead makes sense,
> >> for example, I cannot even answer this simple question:
> >> 
> >>     Would it make sense to have a third mode, "check out if the
> >>     working tree is clean, detach otherwise"?
> >
> > I imagine that some developer might find that useful. If you insist, I
> > will implement it, even if I personally deem this mode way too
> > complicated a concept for myself to be used safely.
> 
> You have been around long enough to know that adding a feature of an
> unknown value is the last thing I would ask, don't you?

> I am essentially saying this:
> 
>     I do not see why and the patch and its documentation do not
>     explain why it is useful, but Dscho wouldn't have added the
>     feature without a reason better than "just because we can do
>     so", so let's assume the mode is useful for some unknown reason.
>     Would people find "updateInstead if able otherwise
>     detachInstead" even more useful for that same unknown reason?