Re: several quick questions

From: Linus Torvalds <torvalds@osdl.org>
Date: Feb 14, 2006, 20:40 UTC
Message-ID: <Pine.LNX.4.64.0602141224110.3691@g5.osdl.org>
In-Reply-To: <87fymlvgzv.wl%cworth@cworth.org>

On Tue, 14 Feb 2006, Carl Worth wrote:

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