Re: several quick questions

[Carl Worth <cworth@cworth.org>]

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

On Tue, 14 Feb 2006 12:40:24 -0800 (PST), Linus Torvalds wrote:
>
> That's really my point. It all boils down to the same three operations: 
> "git branch", "git checkout" and "git reset".

Yes. I understand that much.

> I think that does exactly what you ask for, I just don't really see the 
> point. The downside of cg-seek is that you're really really limited to 
> what you can do with it.

Well, I think it would be useful to generalize and export what
git-bisect currently does even if there are no limitations added to
it. If nothing else, it's a tiny bit of sugar to allow exploring the
tree without having to invent a branch name first.

So I'd be happy with "git seek" even if git-commit didn't refuse to
commit on the seek branch, (but I still think that limitation makes
sense---see below).

> For example, if you hit a compile error, you can _literally_ fix that 
> compile error AND COMMIT that state, and when you then mark that commit 
> "good" or "bad" when you continue to bisect, bisection will actually do 
> the right thing. Something that would be impossible in a "seek" 
> environment, where you don't have a branch that you can do
> development on.

The only difference in the "seek" case would be that you would be
required to create a branch before committing, right?

And this would have the benefit of not leaving the commit object
dangling after continuing the bisect, wouldn't it?

You've pointed out that branches are free in terms of what git has to
do. I'm saying that they're not free for the user who bears the cost
of inventing a name. And in the case of any commit-while-seeking, it's
at the time of the commit itself that the user has enough information
to invent a useful name, not prior to seeking, (when the user is still
trying to figure things out).

-Carl

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