* Re: Getting new branches from remote repo.
2006-11-13 9:17 ` Karl Hasselström
@ 2006-11-13 16:57 ` Matthias Hopf
2006-11-13 17:44 ` Shawn Pearce
2006-11-13 18:17 ` Junio C Hamano
2 siblings, 0 replies; 9+ messages in thread
From: Matthias Hopf @ 2006-11-13 16:57 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, Alexander Litvinov, git
On Nov 13, 06 10:17:36 +0100, Karl Hasselström wrote:
> > > 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.
> >
> > 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.
>
> 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".
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
--
Matthias Hopf <mhopf@suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ labs www.mshop
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Getting new branches from remote repo.
2006-11-13 9:17 ` Karl Hasselström
2006-11-13 16:57 ` Matthias Hopf
@ 2006-11-13 17:44 ` Shawn Pearce
2006-11-13 17:53 ` Karl Hasselström
2006-11-13 18:17 ` Junio C Hamano
2 siblings, 1 reply; 9+ messages in thread
From: Shawn Pearce @ 2006-11-13 17:44 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, Alexander Litvinov, git
Karl Hasselstr?m <kha@treskal.com> wrote:
> On 2006-11-12 20:49:33 -0800, Junio C Hamano wrote:
> > 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.
>
> 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".
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. :-)
--
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Getting new branches from remote repo.
2006-11-13 17:44 ` Shawn Pearce
@ 2006-11-13 17:53 ` Karl Hasselström
0 siblings, 0 replies; 9+ messages in thread
From: Karl Hasselström @ 2006-11-13 17:53 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Alexander Litvinov, git
On 2006-11-13 12:44:57 -0500, Shawn Pearce wrote:
> Karl Hasselström <kha@treskal.com> 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".
>
> And also to automatically stop fetching any branch which is no
> longer listed on the remote system, rather than reporting a "Fetch
> failure".
Yes.
> 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. :-)
Sounds like good default behavior. But I smell the potential for
another command flag here. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Getting new branches from remote repo.
2006-11-13 9:17 ` Karl Hasselström
2006-11-13 16:57 ` Matthias Hopf
2006-11-13 17:44 ` Shawn Pearce
@ 2006-11-13 18:17 ` Junio C Hamano
2006-11-13 18:40 ` Jakub Narebski
2 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2006-11-13 18:17 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
Karl Hasselström <kha@treskal.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.
>
> 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".
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Getting new branches from remote repo.
2006-11-13 18:17 ` Junio C Hamano
@ 2006-11-13 18:40 ` Jakub Narebski
0 siblings, 0 replies; 9+ messages in thread
From: Jakub Narebski @ 2006-11-13 18:40 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> - 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.
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?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 9+ messages in thread