1

My Employer just now is switching to git, so my cowokers are still somewhat inexperienced. What they did now, concerned me, so I'm writing this up.

They cloned a git repository on a machine, then shared that repository via windows share. Now, on the machines that the repository is being shared to, they work on it. This works surprisingly well, as long as no more than one person is working at the same time.

Nothing exploded yet, but I have a bad feeling about this.

What could go wrong? Or is this actually safe to do?

Before someone asks: They are doing this because that shared directory has scripts on it they dont want to copy to their machines. I tried talking them out of it, but they like the idea a lot.

Bob Michaelsen
  • 45
  • 8
  • 1
    I would assume that only one version of git is used at a time. What does `git --version` output? – evolutionxbox Apr 15 '21 at 09:05
  • That is a bold assumption... My own version is 2.26.2.windows.1, their's is definitely not older than mine. (Might be newer though) – Bob Michaelsen Apr 15 '21 at 09:08
  • 2
    Also are multiple people working on the repo via windows share? If so, they probably should stop and clone their own copy instead. – evolutionxbox Apr 15 '21 at 09:10
  • There are multiple people working via share. As I said, I tried to stop them, but they are very confident. I just dont know enough about Git to know what might break... – Bob Michaelsen Apr 15 '21 at 09:12
  • 1
    I know this is not you doing this, but that is bad idea. The whole point of git is it is decentralised. Git is not designed for to be used by multiple users at once. – evolutionxbox Apr 15 '21 at 09:13
  • You said, "that shared directory has scripts on it they dont want to copy to their machines." But they can still run the scripts from the mapped drive, can't they? (Why is the script on, say the S: drive, any different than it being on the C: or D: drive?) – TTT Apr 15 '21 at 14:53

1 Answers1

6

If they all only ever read from this shared area, it's OK. (They must all stop reading while anyone updates the shared area.)

Writing to shared areas is generally a bad idea, because:

  • two people could try to write to the same file;
  • one person could try to read a file while someone else writes it.

There are systems that try1 to reconcile this sort of thing (e.g., Dropbox). Git is not one of them. Don't do it. (Don't put a Git repository in a Dropbox area either.)

Basically, what happens when people do this sort of thing is that it works for a while, then it breaks and nobody can figure out precisely what happened.2 (This is the same thing that happens with programs written in languages that allow thread or other concurrency races.)

1The word try is here for a reason: these systems always have some corner cases where they cannot be sure which version is the right "latest" version, and start doing things like turning file.ext into file.ext (1) and file.ext (2) and forcing the user to resolve the collision. Doing this to a crucial Git internal file (such as the file that holds the HEAD ref) will break a repository.

2In some similar circumstances, I've been well-paid to figure out what happened and/or clean up the mess. As consulting gigs go, these aren't bad.

torek
  • 448,244
  • 59
  • 642
  • 775
  • 1
    Of course it's best to learn from the experience of others, but some folks don't want to listen. This feels like a situation wherein the "system" will "teach" the coworkers that this is a bad idea (eventually). If it's not a safety critical system, you might have to just let them crash. – Randy Leberknight Apr 15 '21 at 18:05