Re: several quick questions

On Tue, 14 Feb 2006, Carl Worth wrote:

quoted

What a strange thing to ask for.

It's pretty common in other tools.

Well, it's pretty common in git too. But in git, the notion of "branch" 
really has been made so cheap that it's basically a no-op.

The "overhead" of creating a branch is literally the cost of writing one 
(small) file.

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

Right. And "git bisect" very much does exactly that. It creates a 
temporary branch for bisection (the branch is called "bisect", one of the 
less confusing naming decisions in git ;)

That's really my point. It all boils down to the same three operations: 
"git branch", "git checkout" and "git reset".

In fact, if you look into git-bisect, you'll notice that it doesn't even 
use "git reset" internally. It _literally_ creates a new branch (which it 
does by hand for some strange reason, but never mind) called "new-bisect", 
and then does "git checkout new-bisect" followed by renaming the branch 
back to "bisect" (which it again does by hand).

So "git bisect" may actually get its hands dirty by knowing a bit too much 
about the internal workings of git branches, but conceptually, it really 
does just

	git checkout -b new-bisect <newrev>

to switch its state around.

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.

Pasky did this before the "multi-branch" thing was common, and calls it 
"cg-seek". 

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.

For example, it may be "overhead" to have a dummy branch for bisection, 
but it means (for example) that you can actually do real work on the point 
that "git bisect" points you to.

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.

I realize that when you come from an environment where branches are big 
things, this is kind of strange. But in git, a branch is literally a 
single file that is 41 bytes in size. That's it. No more, no less.

		Linus