Re: Antw: Re: Missing branches after clone
- From
Philip Oakley <philipoakley@iee.org>
- Date
- May 15, 2019, 07:34 UTC
- Message-ID
- <b75bd892-b216-3c7d-f9e7-4470300e02fc@iee.org>
- In-Reply-To
- <5CDAAB56020000A100031334@gwsmtp.uni-regensburg.de>
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 > > >