From: Maaartin-1 <grajcar1@seznam.cz>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Tracking branches and pulling on remote
Date: Wed, 05 Jan 2011 17:40:26 +0100 [thread overview]
Message-ID: <4D249EFA.5050408@seznam.cz> (raw)
In-Reply-To: <20110105050108.GA5884@sigill.intra.peff.net>
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.
next prev parent reply other threads:[~2011-01-05 16:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-05 0:58 Tracking branches and pulling on remote Maaartin
2011-01-05 5:01 ` Jeff King
2011-01-05 16:40 ` Maaartin-1 [this message]
2011-01-05 16:44 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D249EFA.5050408@seznam.cz \
--to=grajcar1@seznam.cz \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).