Re: keeping remote repo checked out?

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 28, 2005, 22:26 UTC
Message-ID: <Pine.LNX.4.64.0511281420390.3263@g5.osdl.org>
In-Reply-To: <20051128212804.GV22159@pasky.or.cz>

On Mon, 28 Nov 2005, Petr Baudis wrote:

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

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