Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone

[Jakub Narebski <jnareb@gmail.com>]

Andy Parkins wrote:

> Without any specification in the .git/config file, git-pull will execute
> "git-pull origin"; which in turn defaults to pull from the first "pull"
> definition for the remote, "origin".
> 
> This is a difficult set of defaults to track for a new user, and it's
> difficult to see what tells git to do this (especially when it is
> actually hard-coded behaviour).  To ameliorate this slightly, this patch
> explicitly specifies the default behaviour during a clone using the
> "branch" section of the config.
> 
> For example, a clone of a typical repository would create a .git/config
> containing:
>   [remote "origin"]
>   url = proto://host/repo.git
>   fetch = refs/heads/master:refs/remotes/origin/master
>   [branch "master"]
>   remote = origin
>   merge = refs/heads/master
> 
> The [branch "master"] section is such that there is no change to the
> functionality of git-pull, but that functionality is now explicitly
> documented.

This doesn't help newbies if they do "git pull" on branch other than
"master". Git would fetch (a) from default remote "origin" (which can
be unexpected a bit) (b) into current branch (which can be very
unexpected for newbie) (c) the first branch in remote (which can be
very unexpected).

The part (c) could be ameliorated (especially when globbing/regexp
matching would get into 'master') with "Merge:" line in remotes file
and equivalent remote.<name>.merge which would specify explicitely
the branch to be merged, instead of using first branch.

> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
> This is really to help newbies.  By explicitly documenting the default
> behaviour, it makes it clearer what is going on.  It also means no routing
> through documentation to find out what config option needs changing.

Very nice.
 
> It's possible that we would want to remove the default behaviour entirely
> if there is no "branch" definition in the config.  That would prevent
> accidents by users who don't know what pull does fully yet.

Perhaps protected by config option and/or pull option... or perhaps not.
Refuse pulling into current branch if it doesn.t have branch.<name>.remote
matching current remote and doesn't have branch.<name>.merge entry, unless
of course refspec is provided.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git