On Wed, 18 Jan 2017 02:26:16 -0800 (PST) Ralf Tobel <[email protected]> wrote:
[...] > Now I tried your suggestion below instead of 'git clone > path/to/git/bundle' to create the clone: > git init target > cd target > git fetch -u path/to/git/bundle 'refs/*:refs/*' > git reset --hard [...] > This works! Thanks for your help! > > I still do not understand why I have to use different commands when > cloning the bundle instead of the original repo [...] Because that's how `git clone` works. Let's cite its manual: | Clones a repository into a newly created directory, creates | remote-tracking branches for each branch in the cloned repository | (visible using git branch -r), and creates and checks out an initial | branch that is forked from the cloned repository’s currently active | branch. | | After the clone, a plain git fetch without arguments will update | all the remote-tracking branches, and a git pull without arguments | will in addition merge the remote master branch into the current | master branch, if any (this is untrue when "--single-branch" is | given; see below). Consider reading it faithfully sentence-by-sentence, specifically: 1. "creates remote-tracking branches for each branch in the cloned repository (visible using `git branch -r`)" 2. "creates and checks out an initial branch that is forked from the cloned repository’s currently active branch." As you will be able to gather, the repository created by `git clone` normally always ends up with a single local branch created and checked out. The final missing bit to this puzzle is how local repository and remote repositories it talks to *relate* to each other. Newcomers to Git seem to always inevitable approach it with a certain mindset which makes them consider the local repository and its remote repositories as being essentially "the same" -- just located in different places. Unfortunately (for newcomers, that is ;-)), Git was built to support a different mindset. Please consider reading [1] where I tried to explain these matters to someone else in a great level of detail. (I know my writing is somewhat heavyweight, but at least I tried.) The major takeaway from [1] with regard to the issue at hand is that the remote branches kept in a repository have little to no sense *outside* of it, and that's why they are not cloned by `git clone`. This command only clones the branches (or a single branch if specifically told to do so) and all the tags which happen to point to any object reachable from those branches being cloned. To reiterate, the remote branches, which live in a completeley different namespace from "normal" branches are simply not cloned, and my "trick" with explicit `git fetch` was using a special "refspec" (short of reference specification) to fetch truly all the refs there are in the source repository -- including remote branches and all the tags -- even those which would otherwise not fetched by `git clone`. Hence the sequence of commands I suggested sort of creates an almost faithful "mirror" of the original repository (kept in a Git bundle). 1. https://groups.google.com/d/msg/git-users/mJ0iOIZO8ak/M5WpwNix2lkJ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
