git fetch vs push, git am questions

HI all
I honestly tried to find answers in various docs/books about git and failed, so I have to ask here.
 
1) Is it possible to achieve the same result with git fetch, as I have with git push. I have cloned a bare repository (2) from my repository (1) and 
I want fetch made in (2) get all info contained in (1) . I talk only about 'master' here. git push from (1) to (2) does the job, but git fetch in (1) updates only origin/master, and not master.
I also found that there is a notions of current branch in bare repository (master in my case), that stops my experiments of deleting master and making new master out of origin/master.
How can I change current branch in bare repositry?
 
2) I read that git rebase used 'git am' internally. How can  force git am/apply to create conflicts like rebase does in form
 
<<<<<<old
dksjfd
========

 
instead of *.rej files 

Best regard, Konstantin

On Mon, Dec 06, 2010 at 11:27:55PM +0300, Konstantin Kivi wrote:

[...]

`git pull` does exactly that: fetch + merge (which should result in fast-forward in your case).

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). You can use the `git symbolic-ref` to update the HEAD ref.

[...]

P.S. It's a bit strange you're playing with a bare repository in this way. Usually a bare repository is supposed to be pushed to and pulled from, not the other way round. Not that it's bad, but it may turn out you're inventing a convoluted workflow when there may be a simpler solution.

07.12.10, 03:21, "Konstantin Khomoutov" <flatworm@users.sourceforge.net>:

pull does not work on bare repos.

I think I will understand things better if I get what is 'current branch' for bare repository and how to change it

The repository already exists, so git-clone  will not help

Do you mean something like git symbolic-ref master origin/master ?

Yes, I see that push is easier, I only want to be sure I have full control on what is going on.

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

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

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.

"Konstantin Kivi" <kkivi@yandex.ru> wrote in message news:99351291667275@web152.yandex.ru...

I think the --mirror technology was made for what you are trying to do. I created my bare repo as a mirror, but I see you don't want to recreate your bare repo. However, I think you can convert yours to a mirror by modding your config for that repo. With a bare repo that is a mirror, a git fetch will make the bare repo look exactly like the remote repo it is mirroring. That is, the mirror will get everything that the remote has. If the mirror has extra branches that the remote does not have then the mirror will also keep the extra branches as is. However, I think if you push from the mirror to the remote the remote will get those extra branches so watch out for that (I haven't tried it yet because I don't need to do that.)

You could play around with it on a testcopy of your bare repo:

cp -rp barerepo.git testmirror.git

will make a totally functional copy of your barerepo.git. Then you could mod the config of testmirror.git to try and convert it to a mirror. The mirror technology is on the git-clone manpage. It doesn't explain it in much detail, but this is what I've learned from playing around with it. You can first create a bare repo mirror with git-clone to find out what the config setting are supposed to be.

For the push you can create a test copy of your remote:

cp -rp remote testremote

and then alter the config of testmirror.git to point to testremote. If you are pushing from testremote to testmirror.git then be sure to mod testremote's config to point to testmirror.git. I don't push from my remote to my mirror because I use git fetch to get stuff from the remote to the mirror. You shouldn't need to git push from your remote to your mirror, either. However, you may have valid reasons for doing so, but I'm not sure what they would be.

I am using a mirror very heavily in productional work so I know it works (for what I want). I recommend you play around with it for yourself to get a feel for it and not just go by what I say (the manpage does not explain it very much).

Hope this helps.

v/r, Neal