Re: several quick questions

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]

On Tue, 14 Feb 2006 10:34:35 -0800 (PST), Linus Torvalds wrote:
> On Tue, 14 Feb 2006, Carl Worth wrote:
> > 
> > I don't know if it's the original poster's question or not, but an
> > operation I don't see in the above is "put the working files into the
> > state of a given revision".
> 
> What a strange thing to ask for.

It's pretty common in other tools. For example, many tools have a way
to examine the files from a previous state in a "no current branch"
state. Any attempt to commit from that state would prompt the user to
create a new branch name at that point.

In fact, this is the natural operation for the basis of something like
git-bisect.

> It's actually as efficient as anything else, and there's much less room 
> for confusion. When you want to go back, you can just do a simple
> 
> 	git checkout -f master

OK, the efficiency arguments made elsewhere in the thread make it
clear that these are the operations that need to happen.

But I'd still like to be able to do this without having to invent a
fake branch name, without the ability to accidentally commit on the
fake branch, and without the possibility of accidentally leaving those
commits dangling the next time I seek somewhere else.

So I looked, and git-bisect does use this approach with a fake branch
of "bisect" and by saving the original head ref in $GIT_DIR/head-name
for the sake of the final "git bisect reset".

Also, git-bisect does take advantage of the $GIT_DIR/head-name state
to prevent nested calls to "git bisect start", ("won't bisect on
seeked tree").

That gives a very natural name, "seek", for the operation I'd like.

How about "git seek" for doing the operations above, and using some
reserved branch name, (say "seek"). Then, git-bisect could easily be
built on that, and git-commit could respect the "seek" name and refuse
to commit to it, (could tell the user how to create the branch
necessary to commit from the current point).

There could also be a "git seek reset" to return to the HEAD saved by
the first in a chain of "git seek" operations.

That looks like I minor generalization of existing behavior in
git-bisect, but it would provide an operation that I would find
useful.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]