On 2006-12-06, Andy Parkins <andyparkins@xxxxxxxxx> 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. > > Signed-off-by: Andy Parkins <andyparkins@xxxxxxxxx> > --- > 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 > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html