Re: Cleaning up git user-interface warts

From: Han-Wen Nienhuys <hanwen@xs4all.nl>
Date: Nov 16, 2006, 02:30 UTC
Message-ID: <455BCD2B.6060603@xs4all.nl>
In-Reply-To: <7vhcx0gnbq.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano escreveu:

Show 17 quoted lines

>> FWIW, I regularly mess up with the differences between fetching,
>> pulling and merging.  In particular, having to do a two step process
>> to get remote changes in,
>>
>>   git pull url-to-server master:master
>>      ..error message about not being a fast-forward..
>>
>>   git pull --update-head-ok url-to-server master:master
>>      ..still an error message about update not being a fast-forward..
>>
>>       (sigh)
> 
> Sigh indeed.
> 
> Why don't you do the simple and obvious
> 
> 	git pull url master

It is not all evident from the git-pull man-page that this is the obvious and most common usage.

> or "git pull url" if you already know the master is the branch
> you are interested in.

Because I usually replace verbose commands with shortcuts only when I understand exactly what the shortcut is.

To me it's very unlogical that

   master:current-branch

doesn't work, but

   master:

does work, and does what I'd expect

   master:current-branch

to do. Interestingly, doing

   pull ..url.. master:HEAD

also doesn't merge into the current branch, but rather creates a bogus refs/heads/HEAD

I use the remote:local syntax, because I started using GIT in scripted compiles from copied branches of remote repositories. There the explicit remote:local statements are necessary because there is no default branch.