On Sun, Mar 23, 2008 at 17:00:12 +0100, Johannes Schindelin wrote: > 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@xxxxxx> -- 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
