On Thu, 3 Oct 2013 06:45:14 -0700 (PDT)
dkoleary <dkole...@olearycomputers.com> wrote:
> Absolutely amazing, sir! Your answer is spot on accurate, very
> complete, and very detailed. While I sorry that I put you to that
> much unpaid work, I am very grateful. I'm going to bookmark this
> explanation and refer to it regularly until the concept sticks. I
> have a grasp on it now; but, I'm not sure it's completely there yet.
Thanks for your positive feedback!
I've spotted a minor error in my explanation though: in the sentence
Now when you call `git fetch origin` (or just `git fetch`) in a
repository set up like this, Git sees no refspec passed to it on the
command line and so it looks up the <remote>.fetch configuration
variable in the local repo (in this case it will be origin.fetch), and
if it's found, uses the refspec it defines. Note that contrary to the
the names of the configuration variables should include the word
"remote": remote.<remote>.fetch for the generic form and
remote.origin.fetch for a remote named "origin". You can observe how
that maps to the configuration file sections:
[remote "origin"]
fetch = ...
means to read/write that "fetch" variable in a section we refer to it
by "remote.origin.fetch".
> Some interesting data points that will probably be explained by
> different git versions or the fact that I'm cloning from a bare repo:
>
> * ``git clone --bare ${prod}:/${dir}`` results in a bare clone,
> obviously. The config file, though, doesn't have the remote origin
> stanza to which you referred, nor does ``git remote -v`` display
> anything.
>
> # cat config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = true
> # git remote -v
> #
Quite probably, yes. What does `git --version` return?
> * Easily added and, once done, run the git config command you
> mentioned results in:
>
> # git fetch -v
> From ${prod}:/opt/app/git/filemover
> * [new branch] master -> origin/master
> = [up to date] master -> master
> # git remote -v
> origin ${prod}:/opt/app/git/filemover.git (fetch)
> origin ${prod}:/opt/app/git/filemover.git (push)
[...]
Hmm, there might be a problem with your setup (not a serious one but
anyway): it's somewhat unlikely to see a branch named "origin/master"
in a bare (shared) repository because the name of this branch looks
like a typical name of a remote branch in a someone's normal repository.
So you might have inadvertently pushed a remote branch to your shared
repo using something like `git push --mirror`
(or `git push <remote> refs/*:refs/*` which is essentially the same).
Don't do that from a non-bare repository having a typical setup.
There's no harm by why have this confusion? If it turns out that I'm
correct and someone have inadvertently pushed a remote branch in the
shared repository you could delete it by pushing nothing to it:
git push <remote> :refs/heads/origin/master
--
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/groups/opt_out.
