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