Karl Hasselström [off-list ref] writes:
quoted
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.