Re: Antw: Re: Missing branches after clone

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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







[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux