Re: keeping remote repo checked out?

From: Junio C Hamano <junkio@cox.net>
Date: Nov 28, 2005, 19:35 UTC
Message-ID: <7vsltgtvk4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051128105736.GO22159@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 16 quoted lines

> Dear diary, on Mon, Nov 28, 2005 at 08:48:26AM CET, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> James Cloos <cloos@jhcloos.com> writes:
>> 
>> > Is it possible to arrange that a push does a checkout on the remote
>> > the same way a pull does on the local?
>> 
>> Creative use of hooks/post-update would solve that.
>> 
>> However, you should be very careful if you sometimes edit on
>> server and sometimes push from other machine to the server on
>> the same branch on the server.
>
> Why? At worst you will get files with conflict markers on the server,
> which isn't that huge problem and just what you have to expect when you
> do this kind of thing.

Both of us are right and talking about the same thing. You are right that as long as hooks/post-update is done correctly the one who works on the server should not have to worry. I am right that the hooks/post-update for that setup needs to be done very carefully ;-).

Here are the things whoever is doing the hooks/post-update for this particular setup needs to think about.

 - is it safe to assume that the guy working on the server
   working tree never switch branches?  otherwise, what to do if
   the working tree has different branch checked out when push
   called post-update?

 - should it allow forced-push that sets HEAD to non descendant
   of the current HEAD?  In a shared repository setup,
   disallowing forced-push is a good discipline.  OTOH, if this
   is primarily used as an installation mechanism to a remote
   hosting site, allowing forced-push may be ok.

 - should it do 'git-checkout', 'git-reset --hard HEAD', or
   'git-pull . branch_to_push_into'?  The former two pretty much
   assumes no development happens on the server repository and
   git push is used primarily as an installation mechanism.  The
   latter is to keep a branch, other than "master" that is
   always checked out on the server machine, and have people
   push into a different branch and merge with it automatically
   when a push happens.  what would you do when a merge conflict
   happens?

On a tangent, the last point brings up an interesting shared-repo usage pattern. When you have a shared central repository like CVS, you could arrange things this way:

 * On the shared repository, prepare one branch per developer
   who is pushing into it, plus "master".

 * The developer pull from "master" and work in her private
   repository.  The changes are pushed into her own branch on
   the shared repository machine.

 * The the shared repository machine tries to merge "master"
   into developer branches when the developer branch head is
   updated.  If it does not trivially resolve, the developer
   branch head is left as the last push by the developer
   (i.e. not recording the merge).  If it does resolve, it is
   checked out into playpen area, built and testsuite run, and
   if all look well, "master" is updated with the result of the
   merge.  A notification is sent to the developer to tell which
   of the above actions happened.

   This does not have to happen in the update hook and you
   probably would not want to because it would be a lenthy
   operation.  The update hook can be used to maintain recent
   push log for a cron job that runs the "merge-test-integrate"
   procedure to decide which branch is interesting.

I am not sure if people would find this useful, though.