Re: keeping remote repo checked out?

From: Junio C Hamano <junkio@cox.net>
Date: Nov 28, 2005, 21:46 UTC
Message-ID: <7vd5kksaxw.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051128212804.GV22159@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 18 quoted lines

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

In case it was not obvious, I was not outlining what I would want as a git-wide policy. It was meant as an example of things people need to think about, IOW, what their head policy should be, if they want to use git in a workflow that magically checks things out when a push happens.

Show 7 quoted lines

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

Unless you screw with the branch head under a checked out tree, git-checkout would remove files properly, and "git-reset --hard" would do the right thing even when you update the branch head of a checked out tree. The last one is interesting and might be useful.