On Wed, 10 Jan 2007, Junio C Hamano wrote:
> Andreas Ericsson <ae@xxxxxx> writes:
>
> > ... Since committing on
> > detached heads really should be a very rare case I don't think many
> > people will find this terribly annoying.
>
> Quite the contrary, I would imagine it would be quite natural to
> do throw-away commits and merges on detached head while
> bisecting the history (e.g. commit small fixup to make it
> compile and then mark the result for bisection to hunt for real
> bugs that are hidden by silly compilation problems).
I don't think this would actually work. If you commit your build fix, and
then mark the result as bad, won't bisect skew its choices due to
suspecting that your build fix is the real bug?
I'd think that, if you make changes while bisecting, you probably want to
leave those changes uncommitted, and merge or discard them when testing
other commits.
If anything, I'd think you'd want a rather different sort of commit
mechanism than the usual commit, which says, "whenever you consider commit
{sha1-from-real-history}, use {tree-with-local-changes} instead of
{tree-in-real-commit}." Or, more generally, "in order to get the trees
I want to actually use, this patch (git diff HEAD) needs to be applied to
every commit in some portion of the history including, at least,
get_sha1(HEAD)".
I'm not seeing any actual benefit to causing the history to contain a
dead-end fork off of an antique commit, and then throwing this away. And
committing your change so that it won't get lost, with the intention of
losing it in a little while, doesn't seem to make any sense, either.
(Of course, it also makes sense to do merges, but again, you probably want
to create and temporarily use the working tree resulting from the merge,
not create the commit.)
I think that the workflow that uses regular commits with a detached HEAD
is this: do a series of commits representing real work on top of a remote
branch or a tag, and decide later (once you've tested the results for
worthiness) whether to turn this into a topic branch or throw it away.
But I don't think this is a good match for detached HEAD, because you may
want to do exactly the same thing, but start with a regular local head. I
think the right thing to do is something like "git checkout --anon", which
puts you on a new branch with no name, which will evaporate if you leave
it (as per "git branch -d"; you need to force it if it isn't fully
merged).
So I think the feature which lets you make commits without being on a
branch from refs/heads is actually a different feature from "detached
HEAD", which only shares the aspect that "git branch" has no line with a
"*", because there is no name for what HEAD points to.
(I'd implement "anonymous branch" by putting you on refs/heads/.anon, and
adding rules for this situation to for_each_ref and update_ref; but that's
an implementation detail, and shouldn't affect the intended semantics of
the feature.)
-Daniel
*This .sig left intentionally blank*
-
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