Re: keeping remote repo checked out?
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Nov 29, 2005, 02:35 UTC
- Message-ID
- <Pine.LNX.4.64.0511282027360.25300@iabervon.org>
- In-Reply-To
- <Pine.LNX.4.64.0511281637480.3177@g5.osdl.org>
On Mon, 28 Nov 2005, Linus Torvalds wrote:
Show 15 quoted lines
> On Mon, 28 Nov 2005, Daniel Barkalow wrote: > > > > 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.
The idea is to have something which is private, to match the working tree, which is obviously private (because it doesn't even exist from the point of view of the database). Of course, you don't want most of the branch mechanism, with HEAD pointing to a file, because when you commit, you want to update something else, and when you check out, you want to check out something else. You want to use a normal git branch, but still have git keep track of what it thinks should be in your working tree, regardless of what the branch you're on does, so that checkout doesn't get confused if somebody's pushed to the branch you're on.
Then, if someone pushes to a branch that's checked out, git doesn't lose track of what it put in the working tree, so it can handle the "git checkout" that you do afterwards to update the working tree. Making everything work okay if multiple "git checkout"s happen at the same time is future work, and will definitely involve locking.
-Daniel *This .sig left intentionally blank*