see comment at ** - **.
From: "Konstantin Khomoutov" <flatw...@users.sourceforge.net>
On Wed, 18 Jan 2017 02:26:16 -0800 (PST)
Ralf Tobel <ralf.to...@gmail.com> 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.
** Thanks for highlighting this - I also hadn't fully appreciated that the
bundled rtbs wouldn't normally be cloned without a carefully crafted refspec
for the clone command. **
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
--
Philip
--
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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
