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

From: Peter Baumann <peter.b.baumann@stud.informatik.uni-erlangen.de>
Date: Dec 6, 2006, 12:36 UTC
Message-ID: <slrnendeau.7j4.Peter.B.Baumann@xp.machine.xx>
In-Reply-To: <200612061207.23437.andyparkins@gmail.com>

On 2006-12-06, Andy Parkins <andyparkins@gmail.com> wrote:

Show 29 quoted lines

> 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.
>
> 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.
>

I second that. It took me a while to understand why the first entry in remotes/origin merged with the current branch. I thought it was a bug because sometimes it did the right thing and once in a while nothing went wrong.

Obviously, it have switched the branch. I even tried to made this "buggy" behaviour reproducable to write a bugreport, but after several days the light goes on and I just felt a little bit stupid :-)

> 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.
>

I'm not absolutly sure about this, but with --use-separate-remote this makes sense, because you can easly teach someone new to git that the changes from the remote branches are under refs/remotes/<branches> and (s)he could merge it with git-pull . refs/remotes/$branch

No more clueless users why git pull on master branch updated the working tree and git pull an other branch does nothing.

-Peter

Show 18 quoted lines

>  git-clone.sh |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/git-clone.sh b/git-clone.sh
> index 826fdda..992cb7c 100755
> --- a/git-clone.sh
> +++ b/git-clone.sh
> @@ -413,7 +413,9 @@ then
>  			rm -f "refs/remotes/$origin/HEAD"
>  			git-symbolic-ref "refs/remotes/$origin/HEAD" \
>  				"refs/remotes/$origin/$head_points_at"
> -		esac
> +		esac &&
> +		git-repo-config branch."$head_points_at".remote "$origin" &&
> +		git-repo-config branch."$head_points_at".merge "refs/heads/$head_points_at"
>  	esac
>  
>  	case "$no_checkout" in