Allan Acheampong <[email protected]> writes:
> ... I'm new to git, but I found it very
> confusing to understand the difference between "remote" ,
> "remotes". Is it in the cloned repo, or is it in a remote place?
> If its local, why doesn't it get shown when I do 'git branch' but
> when I do 'git branch -a'.
> ...
> For example, I create a project locally
> with multiple branches, push it, delete it locally and clone it
> back to my machine. On a 'git branch' I would only see the head
> branch.
> ...
> I'd like to know your opinions about that and what you think about
> the suggestion.
Not very interested, for a few reasons:
(1) It is actively harmful if the aim is to blur the distinction
between local branches and remote-tracking branches. New users
will be in a lot of hurt if they are not aware that the
'master' branch in their repository is unique and different
from the 'master' branch of everybody else's repository and the
'origin' remote repository they cloned from.
(2) It is not necessary. You can do interesting things to the
history on your local branch, like creating new commits to grow
the branch, only after checking it out. And modern Git lets you
say
$ git checkout topic
and it DWIMs the request to "check out the topic branch" to do
the equivalent of
$ git branch -t topic origin/topic && git checkout topic
when 'topic' does not exist as your local branch and there is a
single remote (i.e. 'origin') that has a remote-tracking branch
of that same name 'topic'. This lets you create a corresponding
local branch lazily any time you want to work on extending the
work on a branch taken from the remote, and output from "git
branch --list" to be meaningful: it only lists your local
branch, the ones you have already said that you are interested
in working on in this repository.
(3) It makes "git branch --list" output less useful if you create
local branches that correspond to all the branches taken from
the remote. You cannot tell which ones you have worked on and
which ones you haven't even touched yet.
Having said that, it is fairly trivial to script it, if you really
want to do so, ignoring all of the above downsides. Something like:
git for-each-ref --format='%(refname)' refs/remotes/origin/ |
sed -e 's|^refs/remotes/origin/||' -e '/^HEAD$/d' |
while read branchname
do
git show-ref -q --verify "refs/heads/$branchname" ||
git branch -t "$branchname" "origin/$branchname"
done
But for the reasons stated, it is not a particularly good way to
work to start from many local branches that are copies of all the
remote-tracking branches, many of which you may not even touch, so I
personally do not think we would want to add such an option to
"clone". The implementation would be fairly trivial, as you can see
from the "trivial script" above, but it would encourage a wrong
workflow.
Older Git around 1.4.x days used to conflate remote-tracking
branches and local branches, and threw everything in refs/heads/
hierarchy, which had the exact set of problems above, and that is
why modern Git uses refs/remotes/origin/ hierarchy to store the
remote-tracking branches separately, for less cluttered local branch
namespace.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
