Re: Tracking branches and pulling on remote

> On Wed, Jan 05, 2011 at 12:58:47AM +0000, Maaartin wrote:
> 
>> 1.
>> I'm using git for couple of months and still don't get it. In a new repo a have 
>> two branches: master and X. I pushed both to the server, everything seems to 
>> work. However, there's origin/master but no origin/X in my repo. When I execute
>> git fetch --all -v
>> only master gets fetched. I've created an entry in the .git/config, no change. 
>> I've tried things like
>> git branch --track X origin/X
>> and all of them ends with an error message. Finally I've found out that
>> git config --add remote.origin.fetch refs/heads/X:refs/remotes/origin/X
>> seems to do it, was it right?
> 
> There should already have been a remote.origin.fetch that looked like:
> 
>   $ git config remote.origin.fetch
>   +refs/heads/*:refs/remotes/origin/*
> 
> which is a superset of what you added. If you run the git config command
> I did above, what do you see?

>> 2.
>> I'd like to do some (at least for now) private changes on a foreign project. The 
>> ideal way I think about would be the following:
>> - my local repo is linked to my own server (for backup purposes and for private 
>> cooperation with a college)
>> - the repo on my server is linked to the github hosting the project
>> Now, I'd need to do something like
>> ssh myserver git fetch
>> and everything would be fine. I can do it this way, but I'd prefer something like
>> git remote fetch
>> or even
>> git fetch --remote-too
>> which would first make my server fetch from its origin and then my local repo 
>> fetch from my server. Is there such a thing? Would you recommend me doing it in 
>> a different way?
> 
> There isn't really a shortcut for the two-level thing you're trying to
> do. But consider rearranging your topology to always pull to the local
> repo, and then push changes up to your backup/collaboration server.
> 
> Something like:
> 
>   $ git clone http://github.com/whatever/project.git
>   $ cd project
>   $ git remote add myserver myserver:/path/to/backup repo
> 
> and then your workflow is:
> 
>   : hmm, I feel like working on project. what happened upstream?
>   $ git pull ;# or git fetch origin; gitk origin... ; git merge origin
>   $ hack hack hack
>   : ok, now I have some work to show to my collaborator
>   $ git push myserver
> 
> or possibly:
> 
>   : ok, now what has my collaborator been up to
>   $ git fetch myserver
>   $ gitk myserver/topic
>   : I like it, let's merge
>   $ git merge myserver/topic
>   : Now push back my merge
>   $ git push myserver
> 
> You might also find it convenient to swap which remote is "origin"
> (since it is the default for "git push" without arguments). That is, you
> primarily consider your local repo to be a clone of what's on
> "myserver", but you occasionally fetch and merge changes from upstream,
> like:
> 
>   : ok, what has my collaborator been working on?
>   $ git pull
>   : and what has upstream been up to?
>   $ git fetch upstream
>   : oh, neat stuff. let's merge it
>   $ git merge upstream
>   : and then let's publish it so our collaborator will also work on top
>   : of it
>   $ git push ;# implicitly to origin
> 
> How you want to set it up really depends on which mental model
> represents your workflow best.