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