Re: Antw: Re: Missing branches after clone

[Philip Oakley <philipoakley@iee.org>]

On 15/05/2019 09:45, Ulrich Windl wrote:
>> reasoning for that.
>> It's that you are missing the idea behind the "Branches that track the
>> remote", which are local copies, but not YOUR branches. see below.
>> I clone the GitHub test repo. I get (a copy of) it all (the rtb's). Git
>> _creates_ a local branch 'master' for me. Git checks out the lead remote
>> branch into it. Command prompt returns. I cd into the new repo. I ask
>> what branches _I_ have - just 'master'. I ask about all the branches the
>> repo has - voila, I see all those rtb's in _my_ repo. They are all
>> perfectly valid branch refs.
> Yes, I can mostly follow you there with one exception: In the cloned
> repository the branches are not available under the same name as in the
> original repository (unless I'm totally confused). Therefore a beginner would
> simply assume "they are missing".
> I knew that (which was my use case) git optimizes local copies by linking as
> much as possible, but I don't understand why cloned branches are "soooo
> complicated". (I could understand it as an optimization for network copies)

My use case is that I help on the Git-for-Windows development. So I have 
4 upstream repositories I need to look at:
Git, Junio-git (maintainer), Git-For-Windows, and Dscho-git (gfw 
maintainer).

All of them have a 'master' branch - so I can't have 4 different local 
'master' branches. So, because of history, and hassles Dscho et. al. had 
had to use 'develop', instead of 'master' for their lead branch name, 
but now they are all 'master'. So I just copied that for a while.

Meanwhile I more recently learned that I could simply start my new 
feature branches direct from the remote tracking branches (which are 
local!), and don't actually need a master branch at all!!  But it took a 
long time for it all to click into place in my brain. I've have 50+ 
years of the 'old masters' idea of there being a single unique master 
artefact with all other being second rate copies. Now it's all 
duplicates verified by hashes.
>> It will take a little while to appreciate this extra layer and how to
>> use it, and how Git can 'dwim' (do what I mean) the usage of shortened
>> refs and branch names, so it you try checking out 'change-the-title',
>> git will know to fall back to using the rtb if you haven't created a
>> local version.
>> Hope That Helps.
>> Philip
>>
>> phili@Philip-Win10 MINGW64 / (master)
>> $ cd usr/src
>>
>> phili@Philip-Win10 MINGW64 /usr/src (master)
>> $ git clone https://github.com/octocat/Spoon-Knife.git
>> Cloning into 'Spoon-Knife'...
>> remote: Enumerating objects: 16, done.
>> remote: Total 16 (delta 0), reused 0 (delta 0), pack-reused 16
>> Unpacking objects: 100% (16/16), done.
>>
>> phili@Philip-Win10 MINGW64 /usr/src (master)
>> $ cd Spoon-Knife/
>>
>> phili@Philip-Win10 MINGW64 /usr/src/Spoon-Knife (master)
>> $ git branch
>> * master
>>
>> phili@Philip-Win10 MINGW64 /usr/src/Spoon-Knife (master)
>> $ git branch -a
>> * master
>>     remotes/origin/HEAD -> origin/master
>>     remotes/origin/change-the-title
>>     remotes/origin/master
>>     remotes/origin/test-branch
>>
>> phili@Philip-Win10 MINGW64 /usr/src/Spoon-Knife (master)
>> $
>>
>> --
>> PS What change to the [clone?] man page would have helped you here?
> Maybe confirm this: At this state I could "checkout test-branch" (for
> example), but I could not "merge test-branch", right?
> (Another level of confusion is bash-completion which does not know those
> hidden branches)
for completion, use the remote name first. If the action may be 
ambiguous or dangerous because of Dwimming, then git tends to avoid 
doing it..
>
> OK, reading git-clone again, the following might apply:
> Explain (or refer to) what a "remote-tracking branch" is.
Interestingly, try 'git help glossary' to see the glossary of terms. 
Their are other useful guides that can be access by the same method. 
`git help -g` will list them.
>
> "checks out an initial branch that is forked from the cloned repository’s
> currently active branch" could be simplified to "checks out the active branch
> in the cloned repository"?
>
> Maybe add a paragraph at the end of the DESCRIPTION starting like: "To use
> another branch in the clones repository..."
>
> Maybe also add a pointer to the meanings of "origin" and "remote" (I know that
> the clone source becomes remote/origin)
>
> I wonder whether "This default configuration is achieved by creating
> references to the
> remote branch heads under refs/remotes/origin and by initializing
> remote.origin.url and remote.origin.fetch configuration variables." should
> become "The original repository's URL will be visible as remote/origin in the
> cloned reporitory"
>
> Maybe point out the differences between a "default clone" mand a "--mirror
> clone" in the DESCRIPTION.
>
> The example "Clone from upstream while borrowing from an existing local
> directory:" could benefit from a few explaining words (why would one want to do
> that, i.e. what's the effect?)
>
> None of the examples refers to using another branch than the default branch.
> Maybe add two examples:
> 1: checking out a different branch, 2:merging a different branch to the
> current one
>
> That's what I think.
>
> Regards,
> Ulrich
>
>
Thanks