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

From: Jeff King <peff@peff.net>
Date: Mar 29, 2008, 08:47 UTC
Message-ID: <20080329084743.GA19200@coredump.intra.peff.net>
In-Reply-To: <20080329082757.GA4920@efreet.light.src>

On Sat, Mar 29, 2008 at 09:27:57AM +0100, Jan Hudec wrote:

> Excluding push to non-bare repository and extra work trees, the local
> branches are only ever updated through the HEAD. And as long as they are
> updated with update-ref, it writes the value to the reflog, so HEAD^{0}
> should always equal HEAD.

I assume by HEAD^{0} you mean HEAD@{0}? The first is for peeling tags, while the latter is "the latest reflog entry."

There are a few other ways I can think of to manipulate branches besides through HEAD:

  - git branch -f existing new_ref (though I'm not sure if this works if
    the branch is HEAD)

  - git update-ref refs/heads/branch_that_is_HEAD_but_we_call_it_by_name

However, in both cases the HEAD ref is being munged behind the user's back to some degree, and it can result in a situation where the index doesn't match HEAD anymore. So in both cases, I think the safety check you propose would actually be a benefit.

But I'm not sure if there aren't some "innocent" uses of the second form in people's scripts. For example, a script that operates on HEAD but resolves it internally to "refs/heads/master" and begins using that (and takes care itself to keep the index in sync with the new value written into the ref).

> There are actually two use-cases for this. One is this pushing to non-bare
> repo, which is indeed just shooting oneself in the foot out of lack of
> [...]
> But the other usecase is using additional work trees

I like the fact that it deals with both these cases, and I think it can cover even more. It is a general safety valve for "somebody changed this ref while you weren't looking."

> Besides whith the update above, I no longer propose to keep any new
> information -- just to add a safety-check.

And I like that, too. But I am a little worried that the information will not be sufficient. You are asking for a consistency guarantee of HEAD and HEAD@{0} that comes from using current porcelain. But there are many uses of plumbing that would violate that consistency guarantee. And some of those are exactly what you're trying to catch and warn about. But I suspect there are some false positives (either in people's plumbing-oriented workflows, in other scripts outside of core git, or even in core git itself (I didn't carefully audit how each script works)). And maybe it is OK to warn and force a "-f" there, or cause those scripts to be updated.

By all of these "maybes" what I am saying is "I think this is a promising approach but I am not entirely convinced it won't run into implementation problems." And of course producing a patch is a good first step in figuring it out. :)

-Peff