Re: git push to a non-bare repository

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Mar 19, 2007, 09:19 UTC
Message-ID: <vpq8xdtpp3g.fsf@olympe.imag.fr>
In-Reply-To: <20070319020053.GA11371@thunk.org>

Theodore Tso <tytso@mit.edu> writes:

Show 13 quoted lines

> On Sun, Mar 18, 2007 at 06:31:21PM +0100, Matthieu Moy wrote:
>> I have a repository with a working tree on a machine A, did a clone to
>> another machine B and commited there locally.
>> 
>> I want my changes to get back into the first repository, so I did a
>> "push". The new commit is in the history, I can see it with "git log",
>> but the modifications are not in the working tree.
>
> The general answer (which you've already received) is to tell folks is
> to simply don't use "git push" to remote trees; basically, if you ever
> have a non-bare repository, it doesn't do what you expect, and it will
> leave the novice user horribly confused.  A much better answer is to
> simply go back to machine A, and pull from machine B.

It's not really an option in my case. A is a fixe-IP/fixe-DNS machine, while B is my home machine, behind a NAT modem-router. So, I'd have to figure out my home IP, port-forward the ssh port from the modem to my machine, ...

If I understand correctly the other answers, I have two options:

* Git doesn't manage this case, and doesn't care about me loosing data
  if they're not commited, I'll have to do it myself with hooks.

* Create a bare repository on machine A, and clone it to a non-bare
  repo on which I'll work. But that means duplicating the repository
  on the same filesystem of the same machine. Not really satisfactory
  either. The "light checkout" feature would make it better, but I'm
  still worried about what will happen to my light checkout when
  someone pushes to the repository.

-- 
Matthieu