On Mon, 28 Nov 2005, Linus Torvalds wrote: > 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". 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). The rest should be easy from there, just by locking on that file, since you probably don't care about the race between checking out the head and updating the head. (You would want to have the case for not getting the lock loop until it can get the lock, rather than aborting, however, so that the last version does get checked out even if checkout wins with push but the hook runs before checkout completes.) -Daniel *This .sig left intentionally blank* - 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.htmlReceived on Tue Nov 29 11:19:10 2005
This archive was generated by hypermail 2.1.8 : 2005-11-29 11:19:17 EST