Git push to refs/remotes/mine/master
I am tracking a remote repository, i.e. I have
I know would like to get joe’s changes as soon as possible into my repository.
I don’t want to use
fetch, because I might not be at the computer when he commits. So I tell him: I might be out for shopping, so please just push your changes to
The reason I want his changes asap in my repo is that he turns off his computer in the evening, so I wouldn’t be able to fetch his changes when I come back from shopping.
I know that joe should just setup a bare, public repository, but this is sort of an overhead.
Is pushing to
refs/remotes/joes/master an okay thing to do in such a case?
One Solution collect form web for “Git push to refs/remotes/mine/master”
“best/simplest way to keep multiple (non-bare) Git repos in sync” proposes to deal with that kind of contribution with a post-update hook.
However, there is a more straightforward solution:
As The OP zedoo comments, the thread on git push to a non-bare repo (written by Git maintainer Junio C Hamano, back in 2007) details:
(and it is a great example of a case where it is appropriate to push to a non-bare repo)
receive-pack isn’t updating the
HEADreflog as its updating the actual branch, not
If you pushed instead to
HEADyou should see the
HEADreflog entry too.
What about splitting
HEADwhen you push to the underlying branch, and making
I do not think any of the complication is needed, and I think somebody mentioned a good example, which is a firewalled host that can only be pushed into.
In that example, even though he knows he could fetch in reverse direction in the ideal world, the network configuration does not let him do so, hence need for a push.
To deal with that sanely, people who push between non bare repositories can just forget about pushing into branch heads.
Instead, they can arrange their pushes to be a true mirror image of their fetch that they wish could do.
Athat can only be pushed into, if you could fetch from repo
B, you would:
$ git fetch B
with something like this:
[remote "B"] fetch = refs/heads/*:refs/remotes/B/*
But unfortunately because you can only push into
B, you would run this on
$ git push A
[remote "A"] push = refs/heads/*:refs/remotes/B/*
And after you perform your push, you come to the machine with repo
Aon it, and remembering that what you did was a mirror image of “
git fetch B“, you would:
$ git merge remotes/B/master
and you are done.
In other words, don’t think of
refs/remotes/Bas something that is for the use of “
Its purpose is to track the remote repository
You maintain that hierarchy by issuing fetch in repository
You can issue push in repository
Bto do so as well.
I push into a live repository almost every day.
My typical day concludes like this:
gitster$ git push kernel-org-private gitster$ ssh kernel.org kernel.org$ git merge origin kernel.org$ Meta/Doit -pedantic & kernel.org$ exit ... go drink my tea ...
gitsteris my private development machine
kernel.orgis a machine made available to me by friendly k.org folks
Metais a checkout of my ‘
todo‘ branch and
Doitis a script to build all four public branches.
I always leave ‘
master‘ checked out on my
kernel.orgrepository, and the push from my private machine is done with (I still use the non separate-remote layout):
Push: refs/heads/master:refs/heads/origin Push: refs/heads/next:refs/heads/next Push: +refs/heads/pu:refs/heads/pu Push: refs/heads/maint:refs/heads/maint
So the first thing I do after logging in to
kernel.orgmachine is to run “
git merge origin” to bring the ‘
If you think of ‘
push‘ being mirror image of ‘
fetch‘ you would understand why.
It is like issuing “git fetch” on
kernel.orgmachine to retrieve the hot-off-the-press from my private machine and then “
git merge” it (usually “
git pull” would do that as a
However, sometimes I accidentally leave ‘
next‘ checked out.
If I find out that I left non ‘
master‘ checked out, I would do “
git reset --hard HEAD” before doing anything else, and I do not want my push to sometimes result in detached
HEADand sometimes not.
I do not want to lose the information which branch I was on last (because the next thing I would do is to find out on which branch
If I were annoyed enough by sometimes mistakenly pushing into the live branch, I would switch to separate remote layout and push into
remotes/origin/*hierarchy, and there will
be truly nothing to worry about after that point.