Re: keeping remote repo checked out?

On Mon, 28 Nov 2005, Petr Baudis wrote:
> 
> >  - 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.

There are major locking issues with two people pushing at the same time.

The git logic does the right thing for a non-checked-out branch, but it 
can do the right thing exactly _because_ it's not checked out. It can 
create all the new objects whether the actual push succeeds or not, and it 
can do the final switch-over as a single atomic file operation.

The same is most emphatically _not_ true of "git checkout".

In other words, you need to add your very own locking for the shared 
checked-out tree, and you need to (_within_ that lock) separately remember 
what the _previous_ tree was that was checked out, because you can't just 
rely on the previous head as reported by git, because that will have been 
done ourside your "checked out lock".

And locking really isn't trivial. Especially if you _also_ do this with 
multiple clients touching the same checked-out repo over NFS (which I'd 
seriously suggest you not do).

There's a really good reason why the git core does _not_ do this. It's 
damn complicated.

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