Re: confused about remote branch management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2014-07-23 at 16:51 -0700, Junio C Hamano wrote:
> Ross Boylan <ross@xxxxxxxxxxxxxxxx> writes:
> 
> >> Either
> >> 
> >> 	git fetch origin master:refs/remotes/origin/master
> > Great; that works.
> > Is that procedure supposed to be the usual way I track upstream in this
> > (1.7) version of git?  It seems arcane.
> 
> No, and no.  
Good.  How should I handle getting updates from origin?
> The command is designed so that most of the time you
> can just say "git fetch<ENTER>" without anything extra, which will
> let the configured remote.*.fetch to kick in as the default refspec
> to slurp updates to all the branches.  This is because the branches
> of a single project are supposed to be related, and a single "git
> fetch" goes over a single network connection, establishment of which
> is expected to be a large overhead.  Letting a single invocation of
> "fetch" to slurp updates to _all_ the branches is supposed not to be
> too much overhead over grabbing updates to everything (let alone
> invoking a "git fetch" per each individual branch), and is the
> normal mode of operation.
> 
> A single-shot "git fetch origin master" to explicitly decline
> following of everything other than 'master' *is* the special case.
> 
> And it was a very conscious design decision not to molest the remote
> tracking branch when this kind of explicit command line request is
> made, so that you do not lose track of what commit you _saw_ before
> you ran the command.  That way "git log origin/master..FETCH_HEAD"
> can be used to inspect what got changed since you fetched last time.
> 
> Over the years, with reflogs enabled for everybody, preserving the
> remote tracking branches when the user does not explicitly ask to
> store the result has become much less important.  For this reason,
> modern Git applies, when it sees "git fetch origin master", the
> configured remote.*.fetch as refmap to map the name "master",
> i.e. the only branch you are fetching, to the remote tracking branch
> you use to store the result, i.e. "refs/remotes/origin/master".

For this case I think "get fetch" will attempt to retrieve from the
"personal" remote.

Will "get fetch origin" (with no other arguments) update all the
branches in origin, updating the remote tracking branches, particularly
in git 1.7?  

When I tried "git fetch origin" nothing happened (it returned
immediately with  no messages and git branch -v -a showed the same heads
as before).  It's quite possible none of the other branches have changed
since I last got them, so I don't think the exercise proves much.

Ross


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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]