From: Junio C Hamano <junkio@cox.net>
To: "Karl Hasselström" <kha@treskal.com>
Cc: git@vger.kernel.org
Subject: Re: Getting new branches from remote repo.
Date: Mon, 13 Nov 2006 10:17:02 -0800 [thread overview]
Message-ID: <7vr6w78b4x.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: 20061113091736.GA31693@diana.vm.bytemark.co.uk
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.
next prev parent reply other threads:[~2006-11-13 18:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-13 4:33 Getting new branches from remote repo Alexander Litvinov
2006-11-13 4:49 ` Junio C Hamano
2006-11-13 5:29 ` Alexander Litvinov
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 [this message]
2006-11-13 18:40 ` Jakub Narebski
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=7vr6w78b4x.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=kha@treskal.com \
/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).