Re: keeping remote repo checked out?

Petr Baudis <pasky@suse.cz> writes:

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

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html