On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:
From: David Lang [mailto:david@xxxxxxx]
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.
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html