Re: Is reserving the branch name "bisect" a good thing?

linux@horizon.com writes:

> Without changing this policy in git-checkout, or replicating most
> of git-checkout's code in git-bisect, I can't get away from using
> a head name in refs/heads/.  :-(

I tend to think the above "restriction" a conscious design decision.

> Actually, this leads to a question... suppose I want to manually
> check out some old revision (like "v.2.6.12") for some reason
> (performance testing, say).  How do I do that?
> Do I have to create a branch just to do that?

Absolutely, and that is deliberately so.  You do not want to:

	git checkout v2.6.12
        work work work
        git commit

and move tag v2.6.12 to something that is not v2.6.12.  As you
outlined, that "not moving the tag" check can be done in git
commit and have the user do:

	git checkout v2.6.12
        work work work
        git commit ;# fails
	git checkout -b oops-i-needed-a-branch-after-all
	git commit

but that feels ugly and wrong.

Branches are cheap (just a single file which is a pointer), so
if you prefer neatness:

	git checkout -b test-build v2.6.12
        work work work
        git checkout master ;# when you are done
        git branch -d test-build

Or if you are lazy like me, just keep a single throwaway branch
around, and whenever you feel like:

	git branch -f ta v2.6.12
        git checkout ta
        work work work
        git checkout master ;# when you are done

To test and possibly further develop the git-daemon update topic
branch, which is two revs before the tip of proposed updates
branch:

	git branch -f daemon-updates pu~2
        git checkout daemon-updates
        make
	work work work, find problems and do enhancements
        git commit

then you can say "Hey, Junio I found problem in your daemon
updates topic branch, and if you want my fixes you can pull from
my daemon-updates branch".

> It might be nicer to allow such a checkout and do the checking in
> git-commit, telling you to "git-checkout -b <new_branch>" before
> you check in your edits.

That may be, but it is too confusing.  Everybody needs to be
aware HEAD can point at random place, not necessarily on some
branch.  You happen to have noticed git-commit wants HEAD to be
pointing at a branch and no other random place, but are you
absolutely sure no other tools care?  I don't.

> +# Not generally needed, but provide a cleanup function
> +bisect_stop() {

Why isn't this part of bisect reset?



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html