Re: Auto detaching head options (Re: Working copy revision and push pain)

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> FWIW, I also initially thought this was only a "HEAD" problem, but I
> think Junio's recent argument makes a lot of sense: the problem is not
> one of working tree and HEAD sync, nor even of detached versus ref HEAD.
> The problem is that somebody is using the non-bare repository to do
> stuff (why else would it be non-bare), and you are changing the state
> behind their back.

For people who are overwhelmed by the volume of the list traffic, the
relevant thread is:

  http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062

> Isn't this essentially the 'base' index extension that Junio did a
> while back? It was eventually reverted (or perhaps never merged, I don't
> recall).

It was in 'next' for a while but was reverted before it hit 'master':

  http://thread.gmane.org/gmane.comp.version-control.git/44360/focus=44508

> But maybe you are referencing it here:
>
>>    It would really be similar to the revision number in index proposal,
>>    except less invasive and I actually believe there is a case (some form of
>>    checkout or reset), where we want to read-tree, but not change this ref.
>
> I don't recall the reasons the base extension was not accepted, but I
> think it would make sense to frame your argument as "this is like X;
> people didn't like X for reason Y, but my proposal fixes this by..."

But if you take the position "work tree belongs to the repository owner
and nobody has any business pushing into it sideways; push into acceptance
branch and let the work tree owner merge it when able", the history of the
failed index base experiment becomes irrelevant.