Re: keeping remote repo checked out?

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 29, 2005, 00:43 UTC
Message-ID: <Pine.LNX.4.64.0511281637480.3177@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.64.0511281845280.25300@iabervon.org>

On Mon, 28 Nov 2005, Daniel Barkalow wrote:

Show 5 quoted lines

> 
> We really ought to keep track of what the current checked out tree is, 
> independant of the head that it's supposed to match. Then it would be safe 
> to push to a head that's checked out (it wouldn't update it, but the 
> system would understand what's going on).

Well, that's what branches are all about.

You really have two choices:
 - do it all yourself
 - use git branches

but if you use a special git branch for the checked-out state, then you have to realize that nobody can push directly to it.

You'd have a trigger that triggers on a push to _another_ branch, and then the trigger basically does an automatic "git pull" from that branch (and updates the checked-out state as part of that).

But you _still_ need to do the locking. That's very fundamental. There is no locking in a "git push", exactly because it can push in parallel, by design. And you _cannot_ check out a tree in parallel, so you have to do locking for that.

There's no way you can avoid the locking. You can do shortcuts: for example, you could avoid any explicit locking by having the "checkout" just happen once an hour, with an automatic "pull" from the changed branch. Again, that means that the branch that is checked out can NOT be one of the branches that people push to.

		Linus