git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

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