RE: Question re. git remote repository
- From
- David Lang <david@lang.hm>
- Date
- Jan 17, 2013, 02:49 UTC
- Message-ID
- <alpine.DEB.2.02.1301161843390.21503@nftneq.ynat.uz>
- In-Reply-To
- <A0DB01D693D8EF439496BC8B037A0AEF32209B45@xmb-rcd-x15.cisco.com>
On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:
Show 13 quoted lines
>> From: David Lang [mailto:david@lang.hm] >> >> On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote: >> >>> 1. a bare repository that is normally accessed only by "git push" and >>> "git pull" (or "git fetch"), the central repository model. >> >> pulling from it would not be a problem, I could see issues with multiple >> pushes taking place (the underlying repository would not get corrupted, but you >> will very quickly hit conflicts where the push is not a fast forward and you >> need to merge, not just push) > > How is that different on a network file system, as opposed to using http, ssh, or git-daemon? Don't you get a "not a fast-forward" error, regardless of the protocol?
true.
Show 20 quoted lines
>>> 2. a repository where only one user does "git add" and "git commit", >> while >>> other users will do "git pull", the peer-to-peer model (you pull changes >> from >>> me, I pull changes from you). >> >> >> pulling from a shared repository is probably safe, but I wouldn't bet >> against >> there being any conditions where a pull at the same time someone is doing >> an >> update being able to cause problems. > > Why do you think there would be a problem? > >> The normal thing is to do the pulls through git-daemon, and that does make >> sure >> that what you are pulling is consistant. > > What does "git pull" via git-daemon do to ensure consistency that is different from "git pull" on a network file system?
git pull via the daemon looks at what tree items you have on each end, and then it sends you the items needed to make you match the server. If there are partial updates on the server (due to some update in process) the daemon should not see that, but if you are grabbing the files directly, I would be less confident that you are always safe.
you may _be_ safe, and if others who really know the internals speak up, take their word on it. But, absent assurances that we know that everything is done in the right order in the face of a networked filesystem (which may break visibility of changes due to caching), I would not trust such raw access for updates at all, and only somewhat trust it for read-only use.
David Lang