Re: keeping remote repo checked out?

[Petr Baudis <pasky@suse.cz>]

Dear diary, on Mon, Nov 28, 2005 at 08:35:23PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> 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 ;-).

Aha, then I misunderstood what you wrote before - sorry. Obviously,
you are right. ;-)

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

I wouldn't do anything. Working copy reflects the HEAD; if you don't
update HEAD, you needn't touch the working copy.

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

I would just leave this on the particular head policy.

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

Files should be removed properly, which pretty much excludes the former
two, I think.

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

This seems weird and overcomplicated, and it seems to mirror that GIT
does not want to deal with trees containing local modifications - which
is fine, but I don't think you should go over huge hoops in the workflow
to adjust to that. Just verify in the pre-update hook that the tree
contains no local modifications, and disallow the push otherwise. Cogito
can then use own update hooks which will enable it to handle local
changes more gracefully (albeit still not ideally).

> 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:
..snip..
> I am not sure if people would find this useful, though.

It is certainly quite interesting idea. I'm not sure how useful in
practice is it either, though. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.