git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: keeping remote repo checked out?

From
Daniel Barkalow <barkalow@iabervon.org>
Date
Nov 29, 2005, 00:19 UTC
Message-ID
<Pine.LNX.4.64.0511281845280.25300@iabervon.org>
In-Reply-To
<Pine.LNX.4.64.0511281420390.3263@g5.osdl.org>
On Mon, 28 Nov 2005, Linus Torvalds wrote:
Show 24 quoted lines
> 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*
Previous: Linus TorvaldsNext: Linus Torvalds
Message 8 of 25 in “keeping remote repo checked out?”
  1. James CloosNov 28, 2005
  2. Junio C HamanoNov 28, 2005
  3. Petr BaudisNov 28, 2005
  4. Junio C HamanoNov 28, 2005
  5. Petr BaudisNov 28, 2005
  6. Junio C HamanoNov 28, 2005
  7. Linus TorvaldsNov 28, 2005
  8. Daniel BarkalowNov 29, 2005
  9. Linus TorvaldsNov 29, 2005
  10. Daniel BarkalowNov 29, 2005
  11. Linus TorvaldsNov 29, 2005
  12. Re: keeping remote repo checked out?Daniel Barkalow, Nov 29, 2005
  13. Linus TorvaldsNov 29, 2005
  14. Daniel BarkalowNov 29, 2005
  15. Junio C HamanoNov 29, 2005
  16. Daniel BarkalowNov 29, 2005
  17. Junio C HamanoNov 29, 2005
  18. Matthias UrlichsNov 29, 2005
  19. Junio C HamanoNov 29, 2005
  20. Daniel BarkalowNov 29, 2005
  21. Junio C HamanoNov 29, 2005
  22. Daniel BarkalowNov 29, 2005
  23. Matthias UrlichsNov 29, 2005
  24. James CloosDec 1, 2005
  25. Junio C HamanoDec 1, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.