patchcheckout: allow full refnames for local branches

This teaches git-checkout to strip the prefix 'refs/heads/' from the supplied <branch> argument, to make

	git-checkout refs/heads/master

behave like

	git-checkout master

The former command would detach HEAD.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---

I'm undecided on wheter this is a bugfix or a new feature. It certainly introduces new behaviour, but it passes all the tests.

 git-checkout.sh |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Lars Hjemli <hjemli@gmail.com> writes:

Why is this necessary, may I ask?

On 5/9/07, Junio C Hamano <junkio@cox.net> wrote:

I'm playing around with a gui frontend, and there I use git-for-each-ref to obtain possible arguments for git-checkout. That's how I discovered the 'problem', and solved it by stripping 'refs/heads/' in my frontend. But then I thought it would be nice if 'git-checkout' did the stripping on my behalf, since this might bite others too :)

Lars Hjemli <hjemli@gmail.com> wrote:

If you are building "porcelain" to sit over Git and offer up a pretty view of things, I would encourage you to avoid the stock porcelain. Don't use git-checkout, its stock porcelain. Instead go right to the plumbing. The plumbing doesn't really change behavior as often (if ever).

You can see in git-checkout.sh what actions you need to perform, but its really quite simple if there's no file-level merge involved. Here's the relevent bits from git-gui:

    set cmd [list git read-tree]
    lappend cmd -m
    lappend cmd -u
    lappend cmd --exclude-per-directory=.gitignore
    lappend cmd $HEAD
    lappend cmd $new_branch
    set fd_rt [open "| $cmd" r]
    fconfigure $fd_rt -blocking 0 -translation binary
    fileevent $fd_rt readable \
        [list switch_branch_readtree_wait $fd_rt $new_branch]

    ...
    git symbolic-ref HEAD "refs/heads/$new_branch"

Really all I'm doing is building up an argument list for git read-tree, passing it the commit that is currently in HEAD and the commit I want to switch to ($new_branch), and then I wait for it to finish its job. When its done, I run git symbolic-ref to update the current branch name.

On 5/9/07, Shawn O. Pearce <spearce@spearce.org> wrote:

Thanks, I probably will (also to avoid the shell scripts, since my porcelain is aimed at my co-workers who are stuck on windows)

Lars Hjemli <hjemli@gmail.com> wrote:

Are you building a strictly Win32 native GUI? Or something else? Can I ask what sort of features you are going after? (And if there's a git repository available, feel free to just point me at it and ignore my questions.)

I'm just curious. We seem to have a lot of user interface projects going on at once right now (Eclipse plugin, git-gui, gitk, qgit, tig, gitweb, blameview) and everyone's been learning from each other. I think the competition is good, there's no clear right way to do things here. As the primary author of git-gui, I do want to try and keep current with what the others are up to. ;-)

On 5/9/07, Shawn O. Pearce <spearce@spearce.org> wrote:

It's mono/.net, so I can test it on my linux box and push the binary directly to the poor souls on windows :)

The features I'm focusing on are mostly trivial day-to-day operations of your average coder: status, diff, commit, push, fetch, merge, checkout, log. This should be enough to support our (planned) workflow of one public repo per developer + a shared integration repo with restricted push access + active use of topic-branches.

We currently use subversion, so real branches + real merges are killer arguments for a switch to git. But we also use tortoisesvn, and the "simplicity" of the gui must be met by some tool. Hence me playing around....

If/when it becomes useful, I'll put it up on http://hjemli.net/git/

Heh, I actually considered calling it yagg (but it doesn't deserve a name yet)

Absolutely, nice work btw.

"Lars Hjemli" <hjemli@gmail.com> writes:

Pathspec-less variant of "git checkout" takes two kinds of parameters and has two flavours in its behaviour:

 (1) an exact branch name, in which case it switches to the
     branch; otherwise

 (2) any arbitrary commit object name, in whch case it checks
     out and detaches HEAD.

A tricky part is that an exact branch name is often a perfectly valid commit object name, so rule (1) trumps the rule (2). You just discovered a way to have a detached HEAD at a commit that happens to be at an existing branch -- by naming that commit without using its exact branch name.

An easier way to spell that would be:

	$ git checkout master^0

but

	master^0
        heads/master
        refs/heads/master

are all perfectly good ways to talk about the commit at the tip of the 'master' branch without spelling it as an exact branch name (which is 'master').

On 5/9/07, Junio C Hamano <junkio@cox.net> wrote:

Ok. But if this is intended behaviour, maybe we would want do change the detach-message in this case:

[~/src/git] next$ git checkout refs/heads/master
Note: moving to "refs/heads/master" which isn't a local branch

(sorry for stealing your time with this unimportant stuff, it just surprised me that refs/heads/$branch wasn't treated as a local branch name)