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
