From: Philip Oakley Date: Sat, 18 May 2013 20:53:56 GMT Subject: Re: [PATCH 1/3] fetch: add --allow-local option Message-ID: <2B281B554A864399824A4BCD613A819D@PhilipOakley> In-Reply-To: From: "Felipe Contreras" Sent: Saturday, May 18, 2013 3:23 PM > On Sat, May 18, 2013 at 8:12 AM, Philip Oakley > wrote: >> From: "Junio C Hamano" >> Sent: Friday, May 17, 2013 7:30 PM >> Subject: Re: [PATCH 1/3] fetch: add --allow-local option >> >> [...] >> >> >>> So when "the user" is running "git fetch" on "mywork" branch that >>> happens to be forked from a local "master", i.e. her configuration >>> is set as >>> >>> [branch "mywork"] >>> remote = . >>> merge = refs/heads/master >>> >> >> Was the '.' example illustrative rather than exact. I see no case of >> using >> '.' in my configs. Or am I completely missing the point? (e.g. that >> the use >> of '.' an example of possible future usage)? > > % git checkout -t -b feature master > # work > % git rebase -i > > -- > Felipe Contreras > -- OK, I see it (the dot '.' in the config file) now. I've also located the documentation hidden at the end of git-config(1) under branch..merge, even though your worked example has it under remote not merge. [branch "feature"] remote = . merge = refs/heads/master "If you wish to setup git pull so that it merges into from another branch in the local repository, you can point branch..merge to the desired branch, and use the special setting . (a period) for branch..remote." It feels as if this dwimmery(?) should also be listed in the gitcli(7) documenation and under branch..remote in git-config(1) above it. The use of dot '.' occured in a reply a couple of weeks ago: Sent: Saturday, May 04, 2013 7:51 PM Subject: Re: Pitfalls in auto-fast-forwarding heads that are not checked out? "Jonathan Nieder" wrote: > Another trick is to use "git push": > git push . $production_sha1:refs/heads/master Philip