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

From: Jeff King <peff@peff.net>
Date: Mar 25, 2008, 23:24 UTC
Message-ID: <20080325232424.GB5273@coredump.intra.peff.net>
In-Reply-To: <20080325192552.GC4857@efreet.light.src>

On Tue, Mar 25, 2008 at 08:25:52PM +0100, Jan Hudec wrote:

> The proponents of this (and I also) think, that meaning of HEAD is, or rather
> should be, "the revision your work tree is derived from". If you think it
> should be defined otherwise, can you please say how, so the merits of the
> definitions can be discussed?

I agree with Johannes. It has traditionally been considered "the ref that will be advanced by new commits". And that is why I think detaching the HEAD is just trading one problem for another: your push invisibly mucks with state that the non-bare repository user relies on. When they commit on a detached HEAD, their commits suddenly start going "nowhere" instead of to the branch they thought.

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.

> Note, that that definition implies that HEAD makes no sense for bare
> repository. I think HEAD indeed does not make sense there, but you may of
> course provide different definition where it does.

I think HEAD can be more generally considered the context of the "current" branch. It is the default branch for cloning from bare repositories, and it is the default branch for most operations (logging, starting new branches, etc). So it really is a bit overloaded in that sense.

> Also I believe that it would be very useful to have a ref defined "the
> revision your work tree is derived from", be it HEAD or not. It would:

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). You should be able to find discussion in the list archives.

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..."

-Peff