Missing branches after clone

Missing branches after clone

[Ulrich Windl]

Hi!

While wondering why some branches are not being displayed by "git branch" in a cloned repository, I was reading the obvious man pages (man git-branch, man git-remote), but still couldn't find the reason or the solution. Then I found https://stackoverflow.com/questions/10312521/how-to-fetch-all-git-branches which handles the subject...
But still the most common solution there still looks like an ugly hack.
Thus I suggest to improve the man-pages (unless done already)
My git is as old as 2.12.3, however...

Regards,
Ulrich

Re: Missing branches after clone

[Duy Nguyen]

On Tue, May 14, 2019 at 4:42 PM Ulrich Windl
<Ulrich.Windl@rz.uni-regensburg.de> wrote:
>
> Hi!
>
> While wondering why some branches are not being displayed by "git branch" in a cloned repository, I was reading the obvious man pages (man git-branch, man git-remote), but still couldn't find the reason or the solution.

Local and remote branches are separate concepts. One big difference is
remote branches will be automatically updated when you get updates
from the remote repository, but local branches are only changed by
you.

So if you have to remote branches origin/master and origin/something.
If we automatically create the local branches 'master' and 'something'
for you, just so you can see it in 'git branch', then at the next 'git
fetch' (or 'git pull'), we're going to have a problem. The local
branches will stay the same old values while origin/master and
origin/something are kept uptodate. By the time you switch to and use
branch 'something'. there may be a surprise for you.

Besides, tracking all remote branches only works well when you have
one remote repository. Once you have another one, things get
complicated

> Then I found https://stackoverflow.com/questions/10312521/how-to-fetch-all-git-branches which handles the subject...
> But still the most common solution there still looks like an ugly hack.
> Thus I suggest to improve the man-pages (unless done already)

Yeah I expected to see at least some definition of remote-tracking
branches (vs local ones) but I didn't see one. Room for improvement.
-- 
Duy

Re: Missing branches after clone

[Philip Oakley]

Hi Ulrich,
On 14/05/2019 11:12, Duy Nguyen wrote:
>> Then I foundhttps://stackoverflow.com/questions/10312521/how-to-fetch-all-git-branches  which handles the subject...
>> But still the most common solution there still looks like an ugly hack.
>> Thus I suggest to improve the man-pages (unless done already)
> Yeah I expected to see at least some definition of remote-tracking
> branches (vs local ones) but I didn't see one. Room for improvement.
Yes, the 'remote tracking branch' name [RTB] is very 'French' in its 
backwardness (see NATO/OTAN).

It is a 'branch which tracks a remote', and it is has the 'last time I 
looked' state of the branch that is on the remote server, which may 
have, by now, advanced or changed.

So you need to have the three distinct views in your head of 'My branch, 
held locally', 'my copy of Their branch, from when I last looked', and 
'Their branch, on a remote server, in a state I haven't seen recently'.

Finding a better name for the "RTB", one with an easier cognitive load 
for those trying to understand Git, would be an improvement.

Though there has been a similar issue with 'staging the index'. 
Ultimately it is a new way of thinking about artefacts (perfect 
duplicates, no originals, no master, no copies, just verification 
hashes) so needs new terms and a difficult learning experience.
-- 
Philip

Re: Missing branches after clone

[Duy Nguyen]

On Tue, May 14, 2019 at 5:33 PM Philip Oakley <philipoakley@iee.org> wrote:
>
> Hi Ulrich,
> On 14/05/2019 11:12, Duy Nguyen wrote:
> >> Then I foundhttps://stackoverflow.com/questions/10312521/how-to-fetch-all-git-branches  which handles the subject...
> >> But still the most common solution there still looks like an ugly hack.
> >> Thus I suggest to improve the man-pages (unless done already)
> > Yeah I expected to see at least some definition of remote-tracking
> > branches (vs local ones) but I didn't see one. Room for improvement.
> Yes, the 'remote tracking branch' name [RTB] is very 'French' in its
> backwardness (see NATO/OTAN).

The name is not that bad to me.

>
> It is a 'branch which tracks a remote', and it is has the 'last time I
> looked' state of the branch that is on the remote server, which may
> have, by now, advanced or changed.
>
> So you need to have the three distinct views in your head of 'My branch,
> held locally', 'my copy of Their branch, from when I last looked', and
> 'Their branch, on a remote server, in a state I haven't seen recently'.

What I was looking for is this. I don't think we have something like
this in the man pages (I only checked a few though) and not even sure
where it should be if it should be added to the man pages, git-branch?
git-remote? git-fetch? git-branch.txt might be the best place because
this is still about branches.
--
Duy

Re: Missing branches after clone

[Philip Oakley]

Hi Duy,

On 14/05/2019 11:53, Duy Nguyen wrote:
> On Tue, May 14, 2019 at 5:33 PM Philip Oakley <philipoakley@iee.org> wrote:
>> Hi Ulrich,
>> On 14/05/2019 11:12, Duy Nguyen wrote:
>>>> Then I foundhttps://stackoverflow.com/questions/10312521/how-to-fetch-all-git-branches  which handles the subject...
>>>> But still the most common solution there still looks like an ugly hack.
>>>> Thus I suggest to improve the man-pages (unless done already)
>>> Yeah I expected to see at least some definition of remote-tracking
>>> branches (vs local ones) but I didn't see one. Room for improvement.
>> Yes, the 'remote tracking branch' name [RTB] is very 'French' in its
>> backwardness (see NATO/OTAN).
> The name is not that bad to me.
It was something that I struggled with initially, and its sounds like 
Ulrich had a similar issue.

I expect that those who grow up with the development of Git have an 
organic knowledge that is deeply rooted so the terms will be solidly 
founded for them (along with many other terms and implementation details 
that catch me out ;-).
>> It is a 'branch which tracks a remote', and it is has the 'last time I
>> looked' state of the branch that is on the remote server, which may
>> have, by now, advanced or changed.
>>
>> So you need to have the three distinct views in your head of 'My branch,
>> held locally', 'my copy of Their branch, from when I last looked', and
>> 'Their branch, on a remote server, in a state I haven't seen recently'.
> What I was looking for is this. I don't think we have something like
> this in the man pages (I only checked a few though) and not even sure
> where it should be if it should be added to the man pages, git-branch?
> git-remote? git-fetch? git-branch.txt might be the best place because
> this is still about branches.
>
At the moment its in `git help glossary`, but could be improved, and 
references to it given in the various man pages.
--
Philip

Re: Missing branches after clone

[Duy Nguyen]

On Tue, May 14, 2019 at 6:10 PM Philip Oakley <philipoakley@iee.org> wrote:
> >> It is a 'branch which tracks a remote', and it is has the 'last time I
> >> looked' state of the branch that is on the remote server, which may
> >> have, by now, advanced or changed.
> >>
> >> So you need to have the three distinct views in your head of 'My branch,
> >> held locally', 'my copy of Their branch, from when I last looked', and
> >> 'Their branch, on a remote server, in a state I haven't seen recently'.
> > What I was looking for is this. I don't think we have something like
> > this in the man pages (I only checked a few though) and not even sure
> > where it should be if it should be added to the man pages, git-branch?
> > git-remote? git-fetch? git-branch.txt might be the best place because
> > this is still about branches.
> >
> At the moment its in `git help glossary`, but could be improved, and
> references to it given in the various man pages.

It does not look easy to link to a specific term/section between man
pages. The way user-manual.html does it is to embed the whole
glossary.

I suppose we could still do something similar after breaking down
glossary.txt (like we do with config.txt) the only include relevant
terms. Not sure if this a really good idea to pursue.
-- 
Duy

Re: Missing branches after clone

[Philip Oakley]

On 18/05/2019 13:17, Duy Nguyen wrote:
> On Tue, May 14, 2019 at 6:10 PM Philip Oakley <philipoakley@iee.org> wrote:
>>>> It is a 'branch which tracks a remote', and it is has the 'last time I
>>>> looked' state of the branch that is on the remote server, which may
>>>> have, by now, advanced or changed.
>>>>
>>>> So you need to have the three distinct views in your head of 'My branch,
>>>> held locally', 'my copy of Their branch, from when I last looked', and
>>>> 'Their branch, on a remote server, in a state I haven't seen recently'.
>>> What I was looking for is this. I don't think we have something like
>>> this in the man pages (I only checked a few though) and not even sure
>>> where it should be if it should be added to the man pages, git-branch?
>>> git-remote? git-fetch? git-branch.txt might be the best place because
>>> this is still about branches.
>>>
>> At the moment its in `git help glossary`, but could be improved, and
>> references to it given in the various man pages.
> It does not look easy to link to a specific term/section between man
> pages. The way user-manual.html does it is to embed the whole
> glossary.
>
> I suppose we could still do something similar after breaking down
> glossary.txt (like we do with config.txt) the only include relevant
> terms. Not sure if this a really good idea to pursue.
Mainly I was commenting on the fact that the description is in a guide 
(which isn't well known).
And that we rarely give links to the guides.
For those that end up using the HTML man pages, having hyperlinks to the 
particular section would be useful, though I'm not sure if their is a 
neat way of doing that which is 'nice' for those using the 'man' viewer.
So yes, it's more of a back burner issue, unless some eager tech authors 
suddenly show up;-)
--
Philip

Antw: Re: Missing branches after clone

[Ulrich Windl]

Hi!

The confusing part actually is for me:
"git clone" does NOT "Clone a repository into a new directory", but "clone the current branch into a new directory" (IMHO).
So I was surprised that I couldn't merge branches under the same name in the cloned "repository".
Only "git clone --bare" actually seems to clone "the repository".
I think this is very confusing to new users. At least I didn't quite get the reasoning for that.

Regards,
Ulrich


>>> Philip Oakley <philipoakley@iee.org> schrieb am 14.05.2019 um 12:33 in
Nachricht <0c9ec78a-9245-e1df-7ec6-a5d77d1a5261@iee.org>:
> Hi Ulrich,
> On 14/05/2019 11:12, Duy Nguyen wrote:
>>> Then I 
> foundhttps://stackoverflow.com/questions/10312521/how-to-fetch-all-git-branch
> es  which handles the subject...
>>> But still the most common solution there still looks like an ugly hack.
>>> Thus I suggest to improve the man-pages (unless done already)
>> Yeah I expected to see at least some definition of remote-tracking
>> branches (vs local ones) but I didn't see one. Room for improvement.
> Yes, the 'remote tracking branch' name [RTB] is very 'French' in its 
> backwardness (see NATO/OTAN).
> 
> It is a 'branch which tracks a remote', and it is has the 'last time I 
> looked' state of the branch that is on the remote server, which may 
> have, by now, advanced or changed.
> 
> So you need to have the three distinct views in your head of 'My branch, 
> held locally', 'my copy of Their branch, from when I last looked', and 
> 'Their branch, on a remote server, in a state I haven't seen recently'.
> 
> Finding a better name for the "RTB", one with an easier cognitive load 
> for those trying to understand Git, would be an improvement.
> 
> Though there has been a similar issue with 'staging the index'. 
> Ultimately it is a new way of thinking about artefacts (perfect 
> duplicates, no originals, no master, no copies, just verification 
> hashes) so needs new terms and a difficult learning experience.
> -- 
> Philip

Re: Antw: Re: Missing branches after clone

[Philip Oakley]

On 14/05/2019 12:49, Ulrich Windl wrote:
> Hi!
>
> The confusing part actually is for me:
> "git clone" does NOT "Clone a repository into a new directory", but "clone the current branch into a new directory" (IMHO).
> So I was surprised that I couldn't merge branches under the same name in the cloned "repository".
> Only "git clone --bare" actually seems to clone "the repository".
> I think this is very confusing to new users. At least I didn't quite get the 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.

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?

>> Philip Oakley <philipoakley@iee.org> schrieb am 14.05.2019 um 12:33 in
> Nachricht <0c9ec78a-9245-e1df-7ec6-a5d77d1a5261@iee.org>:
>> Hi Ulrich,
>> On 14/05/2019 11:12, Duy Nguyen wrote:
>>>> Then I
>> foundhttps://stackoverflow.com/questions/10312521/how-to-fetch-all-git-branch
>> es  which handles the subject...
>>>> But still the most common solution there still looks like an ugly hack.
>>>> Thus I suggest to improve the man-pages (unless done already)
>>> Yeah I expected to see at least some definition of remote-tracking
>>> branches (vs local ones) but I didn't see one. Room for improvement.
>> Yes, the 'remote tracking branch' name [RTB] is very 'French' in its
>> backwardness (see NATO/OTAN).
>>
>> It is a 'branch which tracks a remote', and it is has the 'last time I
>> looked' state of the branch that is on the remote server, which may
>> have, by now, advanced or changed.
>>
>> So you need to have the three distinct views in your head of 'My branch,
>> held locally', 'my copy of Their branch, from when I last looked', and
>> 'Their branch, on a remote server, in a state I haven't seen recently'.
>>
>> Finding a better name for the "RTB", one with an easier cognitive load
>> for those trying to understand Git, would be an improvement.
>>
>> Though there has been a similar issue with 'staging the index'.
>> Ultimately it is a new way of thinking about artefacts (perfect
>> duplicates, no originals, no master, no copies, just verification
>> hashes) so needs new terms and a difficult learning experience.
>> -- 
>> Philip
>
>
>

Re: Antw: Re: Missing branches after clone

[Ulrich Windl]

>>> Philip Oakley <philipoakley@iee.org> schrieb am 15.05.2019 um 09:34 in
Nachricht <b75bd892-b216-3c7d-f9e7-4470300e02fc@iee.org>:
> On 14/05/2019 12:49, Ulrich Windl wrote:
>> Hi!
>>
>> The confusing part actually is for me:
>> "git clone" does NOT "Clone a repository into a new directory", but "clone

> the current branch into a new directory" (IMHO).
>> So I was surprised that I couldn't merge branches under the same name in
the 
> cloned "repository".
>> Only "git clone --bare" actually seems to clone "the repository".
>> I think this is very confusing to new users. At least I didn't quite get
the 
> 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)

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

OK, reading git-clone again, the following might apply:
Explain (or refer to) what a "remote-tracking branch" is.

"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


> 
>>> Philip Oakley <philipoakley@iee.org> schrieb am 14.05.2019 um 12:33 in
>> Nachricht <0c9ec78a-9245-e1df-7ec6-a5d77d1a5261@iee.org>:
>>> Hi Ulrich,
>>> On 14/05/2019 11:12, Duy Nguyen wrote:
>>>>> Then I
>>> 
>
foundhttps://stackoverflow.com/questions/10312521/how-to-fetch-all-git-branch
>>> es  which handles the subject...
>>>>> But still the most common solution there still looks like an ugly hack.
>>>>> Thus I suggest to improve the man-pages (unless done already)
>>>> Yeah I expected to see at least some definition of remote-tracking
>>>> branches (vs local ones) but I didn't see one. Room for improvement.
>>> Yes, the 'remote tracking branch' name [RTB] is very 'French' in its
>>> backwardness (see NATO/OTAN).
>>>
>>> It is a 'branch which tracks a remote', and it is has the 'last time I
>>> looked' state of the branch that is on the remote server, which may
>>> have, by now, advanced or changed.
>>>
>>> So you need to have the three distinct views in your head of 'My branch,
>>> held locally', 'my copy of Their branch, from when I last looked', and
>>> 'Their branch, on a remote server, in a state I haven't seen recently'.
>>>
>>> Finding a better name for the "RTB", one with an easier cognitive load
>>> for those trying to understand Git, would be an improvement.
>>>
>>> Though there has been a similar issue with 'staging the index'.
>>> Ultimately it is a new way of thinking about artefacts (perfect
>>> duplicates, no originals, no master, no copies, just verification
>>> hashes) so needs new terms and a difficult learning experience.
>>> -- 
>>> Philip
>>
>>
>>

Re: Antw: Re: Missing branches after clone

[Philip Oakley]

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

Re: Missing branches after clone

[Junio C Hamano]

Philip Oakley <philipoakley@iee.org> writes:

> It is a 'branch which tracks a remote', and it is has the 'last time I
> looked' state of the branch that is on the remote server, which may
> have, by now, advanced or changed.

Yup, I thought we long time ago decided to discourage use of "remote
branch(es)" in our documentation to help unconfuse users and stick
to the term "a remote-tracking branch" (the "remote-tracking" is a
hyphenated one word)?

> So you need to have the three distinct views in your head of 'My
> branch, held locally', 'my copy of Their branch, from when I last
> looked', and 'Their branch, on a remote server, in a state I haven't
> seen recently'.

Yup.  FWIW, when I need to refer to the last one, I'd always say "a
branch at the remote" to avoid the confusing term "remote branch".

Re: Missing branches after clone

[Philip Oakley]

On 15/05/2019 02:50, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.org> writes:
>
>> It is a 'branch which tracks a remote', and it is has the 'last time I
>> looked' state of the branch that is on the remote server, which may
>> have, by now, advanced or changed.
> Yup, I thought we long time ago decided to discourage use of "remote
> branch(es)" in our documentation to help unconfuse users and stick
> to the term "a remote-tracking branch" (the "remote-tracking" is a
> hyphenated one word)?
I believe we are consistent in using the 'rtb' phrase (I've not checked 
the hyphen), but for those uninitiated in the duplicitous ways of 
distributed versioning systems, they can still think that the phrase is 
simply saying that local branch A will be updated to the state of remote 
branch B when do a fetch from that remote.

I.e. they think tracking is a direct linkage via fetch, rather than an 
indirect linkage via a local rtb (a concept that has not yet entered 
their head, and if if they are aware of the possibility, they haven't 
joined the dots). Hence my spelling it out the 'French' way.
>> So you need to have the three distinct views in your head of 'My
>> branch, held locally', 'my copy of Their branch, from when I last
>> looked', and 'Their branch, on a remote server, in a state I haven't
>> seen recently'.
> Yup.  FWIW, when I need to refer to the last one, I'd always say "a
> branch at the remote" to avoid the confusing term "remote branch".
>
yes, it's tricky. I've shot my foot off a number of times.
Thanks
Philip