>>> Philip Oakley <philipoakley@xxxxxxx> schrieb am 15.05.2019 um 09:34 in Nachricht <b75bd892-b216-3c7d-f9e7-4470300e02fc@xxxxxxx>: > 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@xxxxxxx> schrieb am 14.05.2019 um 12:33 in >> Nachricht <0c9ec78a-9245-e1df-7ec6-a5d77d1a5261@xxxxxxx>: >>> 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 >> >> >>
