On Tuesday 07 November 2006 01:13, Junio C Hamano wrote: > I wonder if it is more consistent and easy to use to just make > this: > > git checkout origin/next > > a synonym to: > > git checkout -b origin/next remotes/origin/next > > when remotes/origin/next exists and heads/origin/next does not. Interesting. I wonder how often there is a real need for that long branch names. IMHO this convenience behavior of git-checkout should target the majority of possible use cases. Is it really better to default to long branch names instead of asking for explicit branch name in the rare case of conflict (ie. multiple remote repositories with same branch names and you want to develop on both these branches locally)? Suppose developer2 uses this scheme, and has a local development branch "junio/next", which is based on your "next" branch. Now I want to work on the "next" branch of developer2, getting a local branch name "developer2/junio/next". > Then "git checkout origin/next" would always mean "I want to > switch to the branch I use to hack on the branch 'next' Junio > has". Do it once and you will get exactly my tip, hack on it, > switch out of it and then do it again and you won't lose your > previous work but just switch to that branch. Ah, now I understand your thinking. I admit it has a compelling elegance. However. Would it not be confusing for newbies (and not only for them) to first reference the remote branch with "origin/next", and afterwards, you get your own development branch by using the exactly same name? IMHO this kind of aliasing is awkward. When you want to start another topic branch on the remote branch, or want to reference the remote branch for diffs, you have to explicitly specify "remotes/origin/next", making for more typing. > That is, something like this... > > --- > > diff --git a/git-checkout.sh b/git-checkout.sh > index 119bca1..f6486c6 100755 > --- a/git-checkout.sh > +++ b/git-checkout.sh > @@ -4,6 +4,16 @@ USAGE='[-f] [-b <new_branch>] [-m] [<bra > SUBDIRECTORY_OK=Sometimes > . git-sh-setup > > +# Automatic forking of local branch based on remote > +if test $# = 1 && > + git show-ref --verify --quiet -- "refs/remotes/$1" && > + ! git show-ref --verify --quiet -- "refs/heads/$1" > +then > + set x -b "$1" "remotes/$1" > + echo >&2 "* Forking local branch $1 off of remotes/$1..." > + shift > +fi I didn't know about "set x" before. Thanks, you never end learning :-) "git-checkout remotes/origin/next" does not work as expected, and if fixed, it still should guard against an existing local branch "origin/next", don't you think? (Ok, it does not work in my patch, too.) What do you think about the setup of the default for "git-pull"? Josef - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html