git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jakub Narebski <jnareb@gmail.com>
Date
Dec 6, 2006, 12:27 UTC
Message-ID
<el6crv$p7e$1@sea.gmane.org>
In-Reply-To
<200612061207.23437.andyparkins@gmail.com>
Andy Parkins wrote:
Show 22 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.

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.

Show 5 quoted lines
> 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
Previous: Johannes SchindelinNext: Andy Parkins
Message 3 of 15 in “Explicitly add the default "git pull" behaviour to .git/config on clone”
  1. Explicitly add the default "git pull" behaviour to .git/config on cloneAndy Parkins, Dec 6, 2006
  2. Johannes SchindelinDec 6, 2006
  3. Jakub NarebskiDec 6, 2006
  4. Andy ParkinsDec 6, 2006
  5. Peter BaumannDec 6, 2006
  6. Josef WeidendorferDec 6, 2006
  7. Jakub NarebskiDec 6, 2006
  8. Johannes SchindelinDec 6, 2006
  9. Josef WeidendorferDec 7, 2006
  10. Junio C HamanoDec 7, 2006
  11. Josef WeidendorferDec 7, 2006
  12. Johannes SchindelinDec 7, 2006
  13. Josef WeidendorferDec 7, 2006
  14. Jakub NarebskiDec 8, 2006
  15. Aneesh Kumar K.VDec 7, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.