Re: Getting new branches from remote repo.

Hello list,

I have a trouble I don't know how to solve. When I am cloning remote repo I automatically get all it's branches stored at my repo (they are listed at .git/remotes/origin). When someone adds new branch(es) to remote repo git pull (git fetch) does not automatically add them to my repo. I have a tool to list all remote branches (git ls-remote --heads origin) but I can't find how to add interesting (or all) branches to by repo.

By the way, how can I clone remote repo created by cloning another repo using git clone --use-separate-remotes ? Even git ls-remote --heads origin does not show all branches taken from that another repo.

"Alexander Litvinov" <litvinov2004@gmail.com> writes:

After finding out $that_new_branch's name, add either

	Pull: refs/heads/$that_new_branch:refs/heads/$that_new_branch

or if you are in "separate remote" school, then perhaps

	Pull: refs/heads/$that_new_branch:refs/remotes/origin/$that_new_branch

to .git/remotes/origin and running git fetch would give you what you want, I think.

Well, the point of "separate remote" is not to pollute local heads/ namespace with refs that merely track remote repository, so if you say "ls-remote --heads" you would not see them. They are not "heads" in that repository.

You would still see them if you say "ls-remote" without --heads.

Thanks for help, these commands solve my trouble:
1. Get remote branches by 'git ls-remote origin refs/remotes/*'
2. Fetch needed branch by adding: 'Pull:
refs/remotes/origin/BRANCH:refs/heads/BRANCH' into .git/remotes/origin

Is there any way to automaticly edit .git/remotes/origin before

On 2006-11-12 20:49:33 -0800, Junio C Hamano wrote:

There really should be a flag to make git fetch do this job. And if we use separate remotes, the flag should probably default to "on".

On Nov 13, 06 10:17:36 +0100, Karl Hasselström wrote:

This was an issue I stumbled upon recently, which was discussed on X.org's mailing list. I wanted to sumarize that here, but didn't have time for that so far.

Right now I use the following UGLY script to do exactly that:

git-ls-remote -h origin | cut -f 2 | perl -e 'while (<>) { chomp; $h{$_}=$_; } open F, ".git/remotes/origin" or die; while (<F>) { print; if (/^Pull:\s+([^: ]*):/) { delete $h{$1}; } } foreach $f (keys %h) { print "Pull: ${f}:$f\n"; }' > newfile mv newfile .git/remotes/origin

(modulo some safety tests), but that doesn't work right for origin files with multiple URL: statements (I very much assume they are possible).

I second that there should be a flag to make git fetch do that automatically, and at least all "git for CVS users" tutorials should include this flag, as this is exactly how CVS works (otherwise you cannot check out another branch that happens to be added upstream).

Matthias

Karl Hasselstr?m <kha@treskal.com> wrote:

And also to automatically stop fetching any branch which is no longer listed on the remote system, rather than reporting a "Fetch failure".

I probably would keep the local ref (they are cheap) just in case the user was counting on that branch and then the remote system pulled the rug out from under them. :-)

On 2006-11-13 12:44:57 -0500, Shawn Pearce wrote:

Yes.

Sounds like good default behavior. But I smell the potential for another command flag here. :-)

Karl Hasselström <kha@treskal.com> writes:

While I do not necessarily agree that "git fetch" is the place to do so, I think it is sensible to have a way to easily manage remotes/$origin file.

Things to consider are:

 - We need to notice new branches at the other end.

 - We need to remember old branches that the user is not
   interested in, so that we do not even ask to add it only
   because it does not have a local tracking branch.

 - We need to notice branches that disappeared at the other
   end.  We may want to offer the choice between droping the
   local tracking branch and keeping it in the 'the last
   fetched' state.

So from the UI point of view, considering that "git fetch" might be called as a part of "git pull", a sensible thing to do would be:

 - Add "Pull-ignored:" lines to list remote branches that the
   user is not interested in to .git/remotes/$origin file, and
   teach existing tools to ignore them.

 - Make "git fetch" to always run "ls-remote" (we would need to
   do this anyway to enable commit walkers to fetch from a
   repository that has packed and then pruned its refs) upfront,
   and do the "noticing" part and issue an info message when
   there are new branches (we should only do this when a
   shorthand from .git/remotes/ is used).

 - Add "git maint-remote" command that lets the user compare
   ls-remote output and Pull: lines from remotes/$origin file,
   and add/modify/delete the mapping to local tracking branches.

I think the last one is probably the easiest for the users if done with something like dialog or whiptail.

Junio C Hamano wrote:

Wouldn't it be easier just to add --all flag to git-fetch, which would fetch _all_ the branches, and --save to write remotes file... or rather appropriate config entry?