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

From: Jan Hudec <bulb@ucw.cz>
Date: Mar 25, 2008, 19:25 UTC
Message-ID: <20080325192552.GC4857@efreet.light.src>
In-Reply-To: <alpine.LSU.1.00.0803231658460.4353@racer.site>

On Sun, Mar 23, 2008 at 17:00:12 +0100, Johannes Schindelin wrote:

Show 10 quoted lines

> On Sun, 23 Mar 2008, Jonathan Watt wrote:
> > As I said, I don't want to update the files in the working copy. Seems 
> > like a different issue to me.
> 
> I understood that.  *yawns*
> 
> But I tried to tell you (unsuccessfully, it seems) that this is not 
> desirable to all users, and therefore it would be a horrible, horrible 
> idea to force the behaviour on other people you seemed to try to force on 
> other people.

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?

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.

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:
 - make the behaviour of push to non-bare repository defined.
 - make additional work trees for a repository (created by
   contrib/workdir/git-new-workdir) safe (the mechanizm could than be an
   option for submodules).

I see two ways to add something to keep track of work tree base version:

1. Make HEAD a special kind of ref, that would contain *both* the symbolic
   name *and* sha1. It would behave as symbolic as long as the sha1 values
   match and as detached when they don't.

   This should actually be relatively small code change, because it would be
   confined to update-ref, symbolic-ref and revparse. It would however be
   quite significant change to the repository format.

2. Create a new special ref BASE? (WORKTREE?), with the right semantics.

   The code change would be a bit more invasive here, as more commands would
   be affected (though I hope the commands share internal code so it would
   only be one checkout and one commit path). It would be smaller change to
   the repository format. It would, however, more stick out, because to find
   out which branch you will commit to would require looking at both HEAD and
   BASE.

   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.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>