Tracking branches and pulling on remote

Tracking branches and pulling on remote

[Maaartin]

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?

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?

Re: Tracking branches and pulling on remote

[Jeff King]

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? If you have a wildcard line like the one
above (which is added during the initial clone), then the config you
added would have done nothing.

Are you absolutely sure that the branch was pushed to the remote side in
the first place? How did you push it?

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

-Peff

Re: Tracking branches and pulling on remote

[Maaartin-1]

On 11-01-05 06:01, Jeff King wrote:
> 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?

No, there had been just the single line

refs/heads/master:refs/remotes/origin/master

and after my change I got

refs/heads/X:refs/remotes/origin/X
error: More than one value for the key remote.origin.fetch:
refs/heads/master:refs/remotes/origin/master

It was probably my fault, I may have copied a config file from elsewhere
(and adapted the URL).

> If you have a wildcard line like the one
> above (which is added during the initial clone), then the config you
> added would have done nothing.

I see.

> Are you absolutely sure that the branch was pushed to the remote side in
> the first place? How did you push it?

Yes, I'm sure. I don't remember how I did it, probably using
git push origin master

I think it's clear now.

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

OK, I swapped origin and upstream and made aliases
	fetchboth = !"git fetch; git fetch upstream"
	fetup = fetch upstream
which is about everything I need for now.

Thanks, Maaartin.

Re: Tracking branches and pulling on remote

[Jeff King]

On Wed, Jan 05, 2011 at 05:40:26PM +0100, Maaartin-1 wrote:

> >   $ 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?
> 
> No, there had been just the single line
> 
> refs/heads/master:refs/remotes/origin/master

Ah, OK, then that is the culprit. And the config line you added was a
reasonable solution (though you may consider simply switching it to a
wildcard to cover any future branches, too).

> OK, I swapped origin and upstream and made aliases
> 	fetchboth = !"git fetch; git fetch upstream"
> 	fetup = fetch upstream
> which is about everything I need for now.

Cool. You can also use "git fetch --all" to do the equivalent of your
fetchboth.

-Peff