Thread (1 message) 1 message, 1 author, 2016-06-15

Re: keeping remote repo checked out?

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:13

Petr Baudis [off-list ref] writes:
quoted
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.
quoted
 - 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.
quoted
 - 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help