Allan Acheampong <> 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

     $ 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
                git show-ref -q --verify "refs/heads/$branchname" ||
                git branch -t "$branchname" "origin/$branchname"

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

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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to