Re: Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2009.10.12 09:49:50 +0200, Johannes Schindelin wrote:
> On Tue, 6 Oct 2009, Euguess@gmail.com wrote:
> > I'ma new user of git and I don't think i will ever have a commit in 
> > git.git, because I'm not a programmer (I'm QA).
[...]
> > As for the solution i would choose the "simplest thing that will work" - 
> > so i think that we just have to notify user about his suicide attempt to 
> > checkout nonlocal branch and offer him a correct syntax to go with.
> >
> > Something like below should work:
> > 
> > % git clone git://git.git git
> > % git checkout next
> > You're attempting to checkout to non-local branch. This will lead to your HEAD
> > being detached (our team is on its way!).
> > Do you want to check out local branch 'next' tracking 'origin/next' instead?
> > y/n
> > 
> > if yes, then:
> > Created branch "next" tracking "origin/next"
> > You can update it with 'git pull'.
> > 
> > If no - abort or continue with checkout to nonlocal branch? ('m not sure if
> > detaching HEAD can provide some benefits if done on purpose)
> > 
> > I hope I'm not missing anything...
> 
> No, I think that is something perfectly fine to expect in a software whose 
> UI complexity is unfortunately pretty much in disagreement with its 
> internal complexity.
> 
> One thing one might add for the technically inclined folks (i.e. those who 
> need to implement, and to see that Git is in dear need of some 
> user-friendliness first): "git checkout" is a porcelain (i.e. a program 
> meant for end-user consumption), and as such should not have a problem to 
> react to isatty(0) (i.e. "is the input coming directly from the 
> console?").

So I didn't mean to chime in, but anyway... A few days ago, uau on #git
said that he thinks that "git clone" shouldn't create any branch heads
at all. Instead, git should learn to do something like "svn up", when
the user checked out a remote tracking branch. That was specifically
meant for users that _don't_ commit, like, say, QA guys ;-)

I didn't quite agree on the idea (feel free to tell me that I just blank
out UI problems :-p), but anyway, I felt like coming up with some hack
that achieves said functionality. The result was inspired by "git
checkout -" and looks at HEAD's reflog to figure out whether the user
has checked out a remote tracking branch the last time he used checkout
to switch branches. I dared to call it "git-up" in my $HOME/bin ;-)

#!/bin/bash
MODE=${1:---merge}

RTB=$(git rev-parse --symbolic-full-name $(git reflog | grep 'checkout: moving from .* to' | head -1 | sed -e 's/.* to //'))

if [ ${RTB:0:13} != "refs/remotes/" ]
then
	echo "You're not on a remote tracking branch"
	exit 1
fi

SRTB=${RTB#refs/remotes/}
REMOTE=${SRTB%/*}
git fetch $REMOTE
git reset $MODE $RTB


It's obviously basically just "git reset" on crack, happily dropping
local commits. A "real" implementation would likely have to have more
checks to ensure that the user is using it in an expected way (like
checking that refs/remotes/whatever..HEAD is empty). And it could be
made to work with regular branch heads as well then, as a "fast-forward
only" way of updating (think "git merge --ff-only", but in a less
illogical way, as "--ff-only" actually means "don't create a merge",
which is kinda weird, at least to me).

As I said, I don't really agree on the idea of not creating any branch
heads on "clone", but maybe it's because I'm not a "don't commit, just
watch" person. And the theoretical "git up" command might be handy for
guys that just want to follow things, and thus don't really need branch
heads. At the moment, I don't have any intentions to improve the hack
(also due to lack of time), but if it seems worthwhile to anyone, feel
free to pick it up.

Björn, -ENOPATCH ;-)