Re: git fetch vs push, git am questions

[Konstantin Khomoutov <flatworm@users.sourceforge.net>]

On Tue, 07 Dec 2010 15:31:23 +0300
Konstantin Kivi <kkivi@yandex.ru> wrote:

>>  `git pull` does exactly that: fetch + merge (which should result in
>>  fast-forward in your case).
> pull does not work on bare repos.
Then the only way to update any branch after fetching I can think of
is using `git update-ref` and the information from FETCH_HEAD.

>>> I also found that there is a notions of current branch in bare
>>> repository
>>>  How can I change current branch in bare repositry?
> I think I will understand things better if I get what is 'current
> branch' for bare repository and how to change it
>>  By re-writing the HEAD ref (this behaviour is documented in the
>> man page of the `git clone` command, see the "--branch" option for
>> instance).
> The repository already exists, so git-clone  will not help
I did not propose to use git-clone, I just stated which section of
which manual page hints at what is considered to be the current branch
in a bare repository when Git clones it.

>>  You can use the `git symbolic-ref` to update the HEAD ref.
> Do you mean something like 
> git symbolic-ref  master origin/master ?
Something like
git symbolic-ref HEAD refs/heads/master

P.S.
I also wonder how did you manage to get origin/master in a bare
repository. When I `git clone --bare` an existing Git repository,
I get one branch named "master" (or whatever branch was current in the
source repository), and in the `git clone` manual page we see:

 --bare
   Make a bare GIT repository. That is, instead of creating
 <directory> and placing the administrative files in <directory>/.git,
 make the <directory> itself the $GIT_DIR. This obviously implies the -n
 because there is nowhere to check out the working tree. Also the branch
 heads at the remote are copied directly to corresponding local branch
 heads, without mapping them to refs/remotes/origin/. When this option
 is used, neither remote-tracking branches nor the related configuration
 variables are created.

Which describes the behaviour I see. So it seems you have somehow
botched setup. Like you took a non-bare repository and just copied its
".git" subdirectory somewhere pretending it's now a bare repo.