* Missing branches after clone @ 2019-05-14 9:41 Ulrich Windl 2019-05-14 10:12 ` Duy Nguyen 0 siblings, 1 reply; 13+ messages in thread From: Ulrich Windl @ 2019-05-14 9:41 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Missing branches after clone 2019-05-14 9:41 Missing branches after clone Ulrich Windl @ 2019-05-14 10:12 ` Duy Nguyen 2019-05-14 10:33 ` Philip Oakley 0 siblings, 1 reply; 13+ messages in thread From: Duy Nguyen @ 2019-05-14 10:12 UTC (permalink / raw) To: Ulrich Windl; +Cc: Git Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Missing branches after clone 2019-05-14 10:12 ` Duy Nguyen @ 2019-05-14 10:33 ` Philip Oakley 2019-05-14 10:53 ` Duy Nguyen ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Philip Oakley @ 2019-05-14 10:33 UTC (permalink / raw) To: Duy Nguyen, Ulrich Windl; +Cc: Git Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Missing branches after clone 2019-05-14 10:33 ` Philip Oakley @ 2019-05-14 10:53 ` Duy Nguyen 2019-05-14 11:10 ` Philip Oakley 2019-05-14 11:49 ` Antw: " Ulrich Windl 2019-05-15 1:50 ` Junio C Hamano 2 siblings, 1 reply; 13+ messages in thread From: Duy Nguyen @ 2019-05-14 10:53 UTC (permalink / raw) To: Philip Oakley; +Cc: Ulrich Windl, Git Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Missing branches after clone 2019-05-14 10:53 ` Duy Nguyen @ 2019-05-14 11:10 ` Philip Oakley 2019-05-18 12:17 ` Duy Nguyen 0 siblings, 1 reply; 13+ messages in thread From: Philip Oakley @ 2019-05-14 11:10 UTC (permalink / raw) To: Duy Nguyen; +Cc: Ulrich Windl, Git Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Missing branches after clone 2019-05-14 11:10 ` Philip Oakley @ 2019-05-18 12:17 ` Duy Nguyen 2019-05-19 0:09 ` Philip Oakley 0 siblings, 1 reply; 13+ messages in thread From: Duy Nguyen @ 2019-05-18 12:17 UTC (permalink / raw) To: Philip Oakley; +Cc: Ulrich Windl, Git Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Missing branches after clone 2019-05-18 12:17 ` Duy Nguyen @ 2019-05-19 0:09 ` Philip Oakley 0 siblings, 0 replies; 13+ messages in thread From: Philip Oakley @ 2019-05-19 0:09 UTC (permalink / raw) To: Duy Nguyen; +Cc: Ulrich Windl, Git Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Antw: Re: Missing branches after clone 2019-05-14 10:33 ` Philip Oakley 2019-05-14 10:53 ` Duy Nguyen @ 2019-05-14 11:49 ` Ulrich Windl 2019-05-15 7:34 ` Philip Oakley 2019-05-15 1:50 ` Junio C Hamano 2 siblings, 1 reply; 13+ messages in thread From: Ulrich Windl @ 2019-05-14 11:49 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Antw: Re: Missing branches after clone 2019-05-14 11:49 ` Antw: " Ulrich Windl @ 2019-05-15 7:34 ` Philip Oakley 2019-05-15 8:45 ` Ulrich Windl 0 siblings, 1 reply; 13+ messages in thread From: Philip Oakley @ 2019-05-15 7:34 UTC (permalink / raw) To: Ulrich Windl, git 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 > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Antw: Re: Missing branches after clone 2019-05-15 7:34 ` Philip Oakley @ 2019-05-15 8:45 ` Ulrich Windl 2019-05-15 13:07 ` Philip Oakley 0 siblings, 1 reply; 13+ messages in thread From: Ulrich Windl @ 2019-05-15 8:45 UTC (permalink / raw) To: philipoakley, git >>> 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 >> >> >> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Antw: Re: Missing branches after clone 2019-05-15 8:45 ` Ulrich Windl @ 2019-05-15 13:07 ` Philip Oakley 0 siblings, 0 replies; 13+ messages in thread From: Philip Oakley @ 2019-05-15 13:07 UTC (permalink / raw) To: Ulrich Windl, git 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Missing branches after clone 2019-05-14 10:33 ` Philip Oakley 2019-05-14 10:53 ` Duy Nguyen 2019-05-14 11:49 ` Antw: " Ulrich Windl @ 2019-05-15 1:50 ` Junio C Hamano 2019-05-15 7:13 ` Philip Oakley 2 siblings, 1 reply; 13+ messages in thread From: Junio C Hamano @ 2019-05-15 1:50 UTC (permalink / raw) To: Philip Oakley; +Cc: Duy Nguyen, Ulrich Windl, Git Mailing List 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". ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Missing branches after clone 2019-05-15 1:50 ` Junio C Hamano @ 2019-05-15 7:13 ` Philip Oakley 0 siblings, 0 replies; 13+ messages in thread From: Philip Oakley @ 2019-05-15 7:13 UTC (permalink / raw) To: Junio C Hamano; +Cc: Duy Nguyen, Ulrich Windl, Git Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-05-19 0:09 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-14 9:41 Missing branches after clone Ulrich Windl 2019-05-14 10:12 ` Duy Nguyen 2019-05-14 10:33 ` Philip Oakley 2019-05-14 10:53 ` Duy Nguyen 2019-05-14 11:10 ` Philip Oakley 2019-05-18 12:17 ` Duy Nguyen 2019-05-19 0:09 ` Philip Oakley 2019-05-14 11:49 ` Antw: " Ulrich Windl 2019-05-15 7:34 ` Philip Oakley 2019-05-15 8:45 ` Ulrich Windl 2019-05-15 13:07 ` Philip Oakley 2019-05-15 1:50 ` Junio C Hamano 2019-05-15 7:13 ` Philip Oakley
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).