threads / discuss / 51090

Missing branches after clone

Subject: Missing branches after clone

## tl;dr

13 messages between May 14, 2019 and May 19, 2019.

replies: 12people: 4as markdown or json

Ulrich Windl· May 14, 2019, 09:41 UTC · lore
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

Duy Nguyen· May 14, 2019, 10:12 UTC · re: Ulrich Windl · lore

Re: Missing branches after clone

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
Philip Oakley· May 14, 2019, 10:33 UTC · re: Duy Nguyen · lore

Re: Missing branches after clone

Hi Ulrich, On 14/05/2019 11:12, Duy Nguyen wrote:

Show 5 quoted lines
>> 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
Duy Nguyen· May 14, 2019, 10:53 UTC · re: Philip Oakley · lore

Re: Missing branches after clone

On Tue, May 14, 2019 at 5:33 PM Philip Oakley <philipoakley@iee.org> wrote:
Show 10 quoted lines
>
> 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.
Show 8 quoted lines
>
> 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

Philip Oakley· May 14, 2019, 11:10 UTC · re: Duy Nguyen · lore

Re: Missing branches after clone

Hi Duy,
On 14/05/2019 11:53, Duy Nguyen wrote:
Show 11 quoted lines
> 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 ;-).

Show 13 quoted lines
>> 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

Duy Nguyen· May 18, 2019, 12:17 UTC · re: Philip Oakley · lore

Re: Missing branches after clone

On Tue, May 14, 2019 at 6:10 PM Philip Oakley <philipoakley@iee.org> wrote:
Show 15 quoted lines
> >> 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
Philip Oakley· May 19, 2019, 00:09 UTC · re: Duy Nguyen · lore

Re: Missing branches after clone

On 18/05/2019 13:17, Duy Nguyen wrote:
Show 23 quoted lines
> 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

Ulrich Windl· May 14, 2019, 11:49 UTC · re: Philip Oakley · lore

Antw: Re: Missing branches after clone

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>:
Show 29 quoted lines
> 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
Philip Oakley· May 15, 2019, 07:34 UTC · re: Ulrich Windl · lore

Re: Antw: Re: Missing branches after clone

On 14/05/2019 12:49, Ulrich Windl wrote:
Show 7 quoted lines
> 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?

Show 34 quoted lines
>> 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
>
>
>
Ulrich Windl· May 15, 2019, 08:45 UTC · re: Philip Oakley · lore

Re: Antw: Re: Missing branches after clone

>>> Philip Oakley <philipoakley@iee.org> schrieb am 15.05.2019 um 09:34 in
Nachricht <b75bd892-b216-3c7d-f9e7-4470300e02fc@iee.org>:
Show 5 quoted lines
> 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 
Show 9 quoted lines
> 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)

Show 39 quoted lines
> 
> 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

Show 8 quoted lines
> 
>>> 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
Show 28 quoted lines
>>> 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
>>
>>
>>
Philip Oakley· May 15, 2019, 13:07 UTC · re: Ulrich Windl · lore

Re: Antw: Re: Missing branches after clone

On 15/05/2019 09:45, Ulrich Windl wrote:
Show 16 quoted lines
>> 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.

Show 42 quoted lines
>> 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.

Show 36 quoted lines
>
> "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
Junio C Hamano· May 15, 2019, 01:50 UTC · re: Philip Oakley · lore

Re: Missing branches after clone

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

Philip Oakley· May 15, 2019, 07:13 UTC · re: Junio C Hamano · lore

Re: Missing branches after clone

On 15/05/2019 02:50, Junio C Hamano wrote:
Show 9 quoted lines
> 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.

Show 7 quoted lines
>> 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

← back to recent threads