Re: [PATCH] checkout: allow full refnames for local branches

Lars Hjemli [off-list ref] writes:

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

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

Why is this necessary, may I ask?

On 5/9/07, Junio C Hamano [off-list ref] wrote:

Lars Hjemli [off-list ref] writes:

quoted

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

Why is this necessary, may I ask?

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

-- 
larsh

Lars Hjemli [off-list ref] 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 :)

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.

-- 
Shawn.

"Lars Hjemli" [off-list ref] writes:

On 5/9/07, Junio C Hamano [off-list ref] wrote:

quoted

Lars Hjemli [off-list ref] writes:

quoted

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

Why is this necessary, may I ask?

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.

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 [off-list ref] wrote:

"Lars Hjemli" [off-list ref] writes:

quoted

On 5/9/07, Junio C Hamano [off-list ref] wrote:

quoted

Lars Hjemli [off-list ref] writes:

quoted

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

Why is this necessary, may I ask?

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.

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.

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)

-- 
larsh

On 5/9/07, Shawn O. Pearce [off-list ref] wrote:

Lars Hjemli [off-list ref] wrote:

quoted

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

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

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

-- 
larsh

Lars Hjemli [off-list ref] wrote:

On 5/9/07, Shawn O. Pearce [off-list ref] wrote:

quoted

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

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

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.  ;-)

-- 
Shawn.

On 5/9/07, Shawn O. Pearce [off-list ref] wrote:

Lars Hjemli [off-list ref] wrote:

quoted

On 5/9/07, Shawn O. Pearce [off-list ref] wrote:

quoted

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

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

Are you building a strictly Win32 native GUI?  Or something else?

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

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

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/

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.

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

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.  ;-)

Absolutely, nice work btw.


-- 
larsh