Git Clone Parameter

Git Clone Parameter

[Allan Acheampong]

Hi,

it would be nice to have a parameter on 'git clone' that not only clones the repo, but also creates local branches for ALL the branches that are in the repo. 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 understand that there are projects that have a lot of branches that are not needed for that specific developer, but still it would be nice if one could specify this at clone time. Something like 'git clone <theR
 epo> -createLocalBranchesForAllBranches' . Of course the param shouldn't be that long. I could write a script with for each in but thats way too much hassle and effort for something that should be there already and I don't think I am the first to get confused by this.

I'd like to know your opinions about that and what you think about the suggestion.
Allan.

Re: Git Clone Parameter

[Ramkumar Ramachandra]

Allan Acheampong wrote:
> I could write a script with for each in but thats way too much hassle

  $ git for-each-ref --format="%(refname)" refs/remotes/origin/ | sed
's/refs\/remotes\/origin\///;/HEAD\|master/d' | xargs git checkout -b

(completely untested ofcourse)

Do you see what the problem is immediately?  There's nothing special
about "origin": I could have branches with the same name on several
remotes.  Without detaching local branches from remote branches, there
is no distributed workflow: your central workflow is just a special
case.

Re: Git Clone Parameter

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Allan Acheampong wrote:
>> I could write a script with for each in but thats way too much hassle
>
>   $ git for-each-ref --format="%(refname)" refs/remotes/origin/ | sed
> 's/refs\/remotes\/origin\///;/HEAD\|master/d' | xargs git checkout -b
>
> (completely untested ofcourse)

You would at least need "xargs -n 1" for the produced command line
to make any sense, and it is wasteful to actually check out each
and every branch to the working tree only to create it.

Re: Git Clone Parameter

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> You would at least need "xargs -n 1" for the produced command line
> to make any sense, and it is wasteful to actually check out each
> and every branch to the working tree only to create it.

Right.  xargs -n 1, git branch, and refname:short.

Re: Git Clone Parameter

[Johannes Sixt]

Am 7/19/2013 11:21, schrieb Allan Acheampong:
> Something like 'git clone <theRepo> -createLocalBranchesForAllBranches'

Perhaps:

$ git clone theRepo
$ git fetch origin refs/heads/*:refs/heads/*

(untested). There may be ways to write the same shorter, but I've lost
track of what is and what is not possible in refspec.

-- Hannes

Re: Git Clone Parameter

[Junio C Hamano]

Johannes Sixt <j.sixt@viscovery.net> writes:

> Am 7/19/2013 11:21, schrieb Allan Acheampong:
>> Something like 'git clone <theRepo> -createLocalBranchesForAllBranches'
>
> Perhaps:
>
> $ git clone theRepo
> $ git fetch origin refs/heads/*:refs/heads/*
>
> (untested). There may be ways to write the same shorter, but I've lost
> track of what is and what is not possible in refspec.

That would overwrite your local branch and would not give you any
tracking, no?

Re: Git Clone Parameter

[Junio C Hamano]

Allan Acheampong <allanadjei@gmail.com> 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.

Re: Git Clone Parameter

[Ramkumar Ramachandra]

Junio C Hamano wrote:
>               git branch -t "$branchname" "origin/$branchname"

A couple of notes here:

1. I use git branch -u personally.  Why the -t variant?
2. Don't we auto-track? (or is that only on checkout)

Re: Git Clone Parameter

[Philip Oakley]

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Friday, July 19, 2013 4:02 PM
> Allan Acheampong <allanadjei@gmail.com> 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'.

Allan,
This (not being sure about local remote branches and distant remote
branches, while coping with multiple remote servers) appears to be a
common problem for new folks, which those well versed in the use of Git
have become well used to so don't see the problem.

For the uninitiated, the lack of distinct terminology can cause no end
of confusion as most explanations presume that you will implicitly
understand the context, which can't be true for such newbies. It doesn't
help that the 'remotes' model of the Git DVCS fits a work flow style
that isn't the same as the expectation of the newbie.

For example, in a larger collaboration there can be many many branches
(on a communal server) that essentially belong to other contributors
which one would never be interested in, and you (and they) would want
ignored.

>> ...
>> 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.

Junio explains below how your suggestion of 'only the head branch'
viewpoint is too limiting (among other things).

That said, if you have a terminology for the distinction between the
confusing aspects (once understood), then that would be worth something
to help ease the path of understanding for others. I had the same
confusions for a while, and even now have to use some of the awkward
terminology I used above, so any improvements in that area would be
useful. -- Branching models are an endless source of discussion!

Philip

>> ...
>> 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.
>

Re: Git Clone Parameter

[Junio C Hamano]

"Philip Oakley" <philipoakley@iee.org> writes:

>> Allan Acheampong <allanadjei@gmail.com> 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 the uninitiated, the lack of distinct terminology can cause no end
> of confusion as most explanations presume that you will implicitly
> understand the context, which can't be true for such newbies.

True.

 * You work in a local repository.

 * You interact with repositories other than the local repository.
   Here, "to interact" mean "exchange the history with", either by
   pushing the commits in the local repository to the other one(s),
   or fetching the commits in the other one(s) to the local
   repository.

   These "other repositories" are "remote repositories" from the
   point of view of the local repository.

   Note that you may have two repositories you use for working on
   the same project, one on your desktop and one on your notebook.
   As far as the repository on your notebook is concerned, the
   repository on your desktop, if you interact with it from the
   repository on your notebook, is a "remote repository" (and the
   one on the desktop views the one on the notebook as "remote").

 * Often we call a "remote repository" just a "remote".  Especially
   when we give a convenience short-name to it, like "origin".

 * When you "clone" from a repository to create a "copy" to work in,
   from that new repository's point of view, the original repository
   is a "remote repository", and "git clone" configures things in
   the new repository so that you can conveniently interact with
   that original repository.  The last part is what lets you say
   "git fetch origin", for example, to interact with the "origin"
   remote.

 * Branches are local to each repository.  It is merely a social
   convention that the primary branch in the repository you cloned
   from (i.e. your "origin") is often called 'master', the primary
   branch in the local repository is called 'master', and you often
   interact with the history of the 'master' branch of the "origin"
   when you are on your 'master' branch.  There is no stronger tie
   between their 'master' and your 'master' other than the social
   convention, but Git makes it easier for you to work that way by
   setting a few configuration variables.

 * Some of the social conventions, and the configuration Git sets up
   to let you follow them easily, allows you to find out where the
   tips of branches at your remotes were, when you last observed
   them (remember, Git is distributed, so you do not ask "right
   now"; instead you have "when you last observed" and "make an
   observation right now" separately).  This is achieved by keeping
   the record of the last observation in "remote-tracking branches".

   The last observed value of the 'master' branch of the remote
   repository "origin" is stored as 'origin/master' (its full name
   is 'refs/remotes/origin/master', but you rarely have to spell it
   out) remote-tracking branch.

   CAVEAT: some older documentation call a "remote-tracking branch"
   just "remote branch", but we have been trying to move away from
   that practice, as it is confusing, because the 'master' branch at
   the 'origin' remote is often called a 'remote branch'.  When you
   see 'remote branch', you need to make sure which one the writer
   meant.

 * "git fetch" (and "git pull", which internally invokes "git
   fetch") is a way to "make the observation now".  "git fetch
   origin" updates your remote-tracking branches for the "origin".

 * "git pull" (and "git pull --rebase") is a way to do the "fetch"
   above and then integrate the history of the branch at the remote
   (which now you know its latest state, because you just observed
   it) with the history you have on your branch.  Again, these
   branches may be named 'master' but the user needs to be aware
   that they are two separate branches (your 'master' branch is just
   as a different entity from the 'master' branch of the remote
   repository as it is your 'next' or any other branch).

   To make it easier to work, git configures the history of which
   branch you obtained/observed from what remote is to be integrated
   with your history per your local branch.  Immediately after "git
   clone", you will typically have your 'master' branch, and the
   branch "knows" that it wants to integrate with the 'master'
   branch at 'origin' remote.  So "git pull" becomes:

    - "git fetch origin", because you will integrate with the
      history that comes from that remote, not other remotes;

    - which updates 'origin/master' remote-tracking branch, and
      possibly other remote-tracking branches under 'origin/'; and

    - integrate your branch with the history of 'origin/master'
      remote-tracking branch.

   We say "your 'master' branch is set to integrate with
   remote-tracking branch 'origin/master'".  It is morally
   equivalent to say "your 'master' branch integrates with the
   'master' branch of 'origin'".

  CAVEAT: people often call this relationship between your 'master'
  branch and 'origin/master' (or the 'master' branch of 'origin'
  remote) "tracking", e.g. "your 'master' branch tracks
  'origin/master'".  Unfortunately, this is a confusing misnomer, as
  the relationship between the 'master' branch of 'origin' and the
  remote-tracking branch 'orign/master' you have in your local
  repository is also called "tracking" (the latter keeps track of
  the former).  You are better off avoid using the word "track" for
  this purose, unless it is very clear from the context.