Git push to refs/remotes/mine/master

I am tracking a remote repository, i.e. I have refs/remotes/joe/master.

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 refs/remotes/joe/master.
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.

  • how to git archive the project directory
  • .gitignore excluding files in all directories
  • Why is the `git subtree` not working even though I have git installed on Ubuntu 12.10?
  • Differences between git submodule and subtree
  • Auth fails on Windows XP with git and tortoisegit
  • Convert portable msysGit to full installed equivalent (but still be portable)
  • 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?

  • Pushing to Hosted project above webroot
  • Paperclip files get deleted after each deploy
  • Install DL4J on Windows
  • Git: What to do when you determine your one project is many and not one project?
  • How to emulate git log --decorate's different colors per branch-type
  • Creating a branch for release snapshots?
  • 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 HEAD reflog as its updating the actual branch, not HEAD.
    If you pushed instead to HEAD you should see the HEAD reflog entry too.

    What about splitting HEAD when you push to the underlying branch, and making HEAD a non-symref?

    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.
    To illustrate:

    On repo A that 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 A from B, you would run this on B instead:

    $ git push A


    [remote "A"] push = refs/heads/*:refs/remotes/B/*

    And after you perform your push, you come to the machine with repo A on 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/B as something that is for the use of “git fetch“.
    Its purpose is to track the remote repository B‘s heads
    You maintain that hierarchy by issuing fetch in repository A.
    You can issue push in repository B to 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$ git merge origin$ Meta/Doit -pedantic &$ exit
    ... go drink my tea ...


    1. gitster is my private development machine
    2. is a machine made available to me by friendly folks
    3. Meta is a checkout of my ‘todo‘ branch and
    4. Doit is a script to build all four public branches.

    I always leave ‘master‘ checked out on my repository, 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 machine is to run “git merge origin” to bring the ‘master‘ up-to-date.
    If you think of ‘push‘ being mirror image of ‘fetch‘ you would understand why.

    It is like issuing “git fetch” on machine to retrieve the hot-off-the-press from my private machine and then “git merge” it (usually “git pull” would do that as a
    single step).

    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 HEAD and 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 Meta/Doit failed).
    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.

    Git Baby is a git and github fan, let's start git clone.