Re: [RFC/PATCH] Make git-{pull,rebase} no-tracking message friendlier

From: Carlos Martín Nieto <cmn@elego.de>
Date: Feb 29, 2012, 17:34 UTC
Message-ID: <1330536843.22763.19.camel@beez.lab.cmartin.tk>
In-Reply-To: <vpqbooit61u.fsf@bauges.imag.fr>

On Wed, 2012-02-29 at 09:09 +0100, Matthieu Moy wrote:

Show 26 quoted lines

> Carlos Martín Nieto <cmn@elego.de> writes:
> 
> > $example is a caller-given string which already contains the whole
> > command (i.e. it's already 'git rebase <upstream branch>' or 'git pull
> > <repository> <branch>').
> 
> OK, I didn't remember the exact message.
> 
> > In this patch I've moved that command to its own paragraph so the
> > usage part of the output gets more visibility.
> 
> I prefer this, yes.
> 
> Perhaps we could go further and try to guess a remote and a branch name
> to give in the example. "git push" already does that to some extend:
> 
>   $ git -c push.default=tracking push
>   fatal: The current branch my-branch has no upstream branch.
>   To push the current branch and set the remote as upstream, use
>   
>       git push --set-upstream origin my-branch
> 
> i.e. if there's a remote configured, then using it in the example makes
> sense. I'm not sure if using the current branch name in the example
> would also be a good thing (it usually is for "push" because most users
> would push to a branch with the same name on the remote end).

We do show the branch name in the 'remote add' text at the end, so we should probably try to use it here as well. What I'm assuming is the most usual case of one remote called 'origin' shouldn't be a problem. I think I'll suppress the last part of the output when there are remotes configured, as we can probably assume that the user is aware of them.

I'm tempted to throw out the second block and say to use either 'git pull $remote $branch' or 'git branch --set-upstream $branch $remote/$branch' and refer to the documentation for more. After all, this is an error message, not a man page.

Show 11 quoted lines

> 
> It may also make sense not to suggest "git remote add" if there's
> already a remote configured. Otherwise, the case, which is probably the
> most common, of:
> 
>   git clone http://example.com/repo
>   cd repo
>   git checkout -b new-branch
>   git pull
> 
> is made far more complex than it should for the newcommer.

Indeed. Removing the last part is probably better for everyone.

cmn