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