0

Can you use a bare repo on a file share as a shared remote repository or is there danger of timing conflicts from multiple users? I can find lots of discussions on how to set it up but when I search for possible timing conflicts all I get are links about merge conflicts.

In other words, if two developers push changes to the remote repo on the shared drive at exactly the same time, is there a possibility of getting the system into a broken state? Remember there is no software running on the shared machine other than disk access management and if both developers have write access... is the git client installed on each user's machine smart enough to handle this kind of timing conflict for a remote repo?

Edit: adding clarifications from posts below. There is NO Git SERVER running on the remote repo - it's just created by a developer with "cd ...remote - git init --bare" and then every developer sets that dir as their remote origin.

My concern is this scenario: 1) dev1 push command checks the state and finds it ready to accept the push, 2) dev2 push command checks the state and finds it ready to accept the push, 3) dev1 pushes and 4) dev 2 pushes...

Ken Otwell
  • 345
  • 3
  • 13
  • To elaborate: there is NO git code running on the repo. It's simply created with "git init -bare" on the shared drive. Then several developers link that as their origin. – Ken Otwell May 30 '14 at 15:26
  • Server or not, all repo access is via the filesystem, and it's all serialized with the same mechanism. – jthill May 30 '14 at 22:21

1 Answers1

1

The user to push second will find their is push rejected (assuming we are discussing changes being made to the same branch by both users).

They will then have to pull/resolve conflicts etc. before pushing back.

In short, it won't be an issue.

bcmcfc
  • 25,966
  • 29
  • 109
  • 181
  • Yup; as long as it's being used as a *repo*, and not simply a shared drive location for the files. (which I guess is obvious; but sometimes the obvious isn't so obvious!) – Andrew Barber May 30 '14 at 15:15
  • @AndrewBarber especially late on a Friday! (Well, I say late. But that depends on your timezone.) – bcmcfc May 30 '14 at 15:16
  • So the pushes are atomic and there is no reason to worry about, for example, this sequence of events: 1) dev1 push command checking the state and finding it ready to accept the push, 2) dev2 push command checking the state and finding it ready to accept the push, 3) dev1 pushes and 4) dev 2 pushes... – Ken Otwell May 30 '14 at 15:22
  • Andrew, actually that is EXACTLY the situation I'm describing. A bare remote repo on a shared drive that is set up as the origin for several developers. Not a git server... no code running to manage the shared repo. – Ken Otwell May 30 '14 at 15:24
  • But you still run `$ git push` and `$ git checkout origin branchname`, etc.? It's just a git repo. Access methodology shouldn't matter. – bcmcfc May 30 '14 at 15:30
  • yes, each developer uses their local copy of git and pushes to the remote on a shared directory. So you're saying that git will somehow lock the remote for the duration of it's push command to make sure there are no interleaved operations going on? – Ken Otwell May 30 '14 at 15:34
  • Yep, it'll be absolutely fine: http://stackoverflow.com/questions/4643998/how-git-works-when-two-peers-push-changes-to-same-remote-simultaneously – bcmcfc May 30 '14 at 15:35
  • Strangely enough, I'm not convinced. That link seems to be talking about pushing to a git server, not a repo on a shared drive. – Ken Otwell May 30 '14 at 15:45
  • Same difference: your shared repo is essentially a server. Semantics. – bcmcfc May 30 '14 at 15:45