On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:

From: David Lang [mailto:da...@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 


2. a repository where only one user does "git add" and "git commit",
other users will do "git pull", the peer-to-peer model (you pull changes
me, I pull changes from you).

pulling from a shared repository is probably safe, but I wouldn't bet
there being any conditions where a pull at the same time someone is doing
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
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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to