1

There are a bunch of questions on sharing a git clone folder among several users, but everything seems to be for Linux (two are linked below). I have the same issue, but for a windows machine. I'm hoping others have done this and have a recommended process.

The hope was that since each user has their own login, each would have their own credentials in the windows credential manager, and their own .ssh folder for keys. This would be sufficient if each user cloned their own version of a repository for doing work.

What, though, happens if user A clones to a directory and logs out, then user B logs in and tries wants to do a pull (to fetch/merge new commits from the remote), make some changes, and push a new change to the remote? I'd like this to succeed, with separate commit info (author info) for each user.

Is --shared helpful in this case? Is there a way to have git's global config apply (name/email, which would be different for each login) vs. user A's information (from the initial git clone, in .git/config)? Is this even possible?

[edit]
Adding detail about the use-case. This was requested in the comments.

I've got a build process that I've automated a fair amount with scripts. It requires a properly configured machine (multiple compilers, patches, etc) and several 3rd party components. The build involves cloning ~50 different repositories, generating makefiles, make, make install (in a specific order on the repos), then running additional packaging/build steps. This takes hours, multiplied by several build configurations for a clean build. To speed up the process, the scripts will generate heuristics that identify whether steps in the chain need to be run (I.e., make can tell if it needs to be rerun, but that doesn't help with make install or subsequent steps). The end result is an installer. We have full rebuilds ~6 months apart for new versions (where we may update the configuration (compiler, etc)), and have minor releases that involve updating and/or adjusting a subset of the repos (push and pull). The scripts may need modification as well, they are in their own git repo.

While the scripting makes the task something I can do without taking too much bandwidth, I'd like to enable a few others on the team to run these steps. Herein lies the dilemma. The "easy" solution is to have a shared account, but that actually makes the git part of this trickier (ssh keys, github tokens), and has many other downsides. Keeping multiple instances of this environment, one for each developer, would be "best" but creates a new problem of synchronizing the machine environment. It also means one developer can't 'help' the others by kicking off long-running processes for them (they'd need to be run by each different account/machine). Allowing multiple developers to use different accounts, but work on the same machine and within the same folder structure seemed like the best compromise.

In effect, the real problem is the build environment. While there are ways to address that (chef, artifact repositories, etc, etc), manually setting up the build environment and sharing the git repos ("exceptional" use of git) seemed reasonable in this case, if it is possible. Thus the question.
[/edit]

[1] Git - multiple users using the same working dir: permissions issues in .git meta-files

[2] https://serverfault.com/questions/26954/how-do-i-share-a-git-repository-with-multiple-users-on-a-machine

Brett Stottlemyer
  • 2,734
  • 4
  • 26
  • 38
  • Why, oh why, would you want to do this? What’s wrong with a clone each? – Biffen Apr 20 '18 at 11:56
  • The vast majority of work is done with each developer working with their own clones in their own environments. We have specific edge cases where this would be extremely helpful. – Brett Stottlemyer Apr 20 '18 at 12:02
  • Is there a reason the linux questions are valid, but a windows version is downvoted? – Brett Stottlemyer Apr 20 '18 at 12:03
  • First off, both of those questions are about limited uses of a shared repo; the first one even bends over backwards to say "I know this isn't how git is used, but here's what we're doing". Secondly, that said, no there's not a reason those are valid while yours is downvoted; in that they should've been downvoted too. – Mark Adelsberger Apr 20 '18 at 12:55
  • @MarkAdelsberger Thanks for the clarification. Is that the point of SO though? Only "best practice" questions are answered and upvoted? Where should people go for help with the exceptions? – Brett Stottlemyer Apr 20 '18 at 14:36
  • My concern is that if I explain my use-case, feedback will focus on whether or not the use-case is valid. And that won't help others who may have similar (but not exactly the same) use-cases. If the answer is that no one should ever, under any conceivable circumstances, do what I'm asking about, I'd appreciate that as an answer with an explanation. – Brett Stottlemyer Apr 20 '18 at 14:51
  • I don't know what to tell you. Like I said, I'd have down-voted any question about multiple users sharing a work tree, not because "it isn't best practice" but because it explicitly works against the tool's model. Ask how to best use a hammer to drive a screw, you'll likely get downvoted. For the record, I didn't vote on your question, which means at least 6 other people feel the same. – Mark Adelsberger Apr 20 '18 at 15:10
  • Can explain "explicitly works against the tool's model" a bit more? I mean that genuinely, as I didn't believe that was the case when asking my question. `--shared` is an officially supported part of the tool, isn't it? That implies some level of recognition for my type of need, at least to me. – Brett Stottlemyer Apr 20 '18 at 15:58
  • 1
    --shared is about sharing files between copies of a repository on the same local system, it has nothing to do with sharing it with multiple people. The idea of Git is every developer works on their own copy then submits changes back to parent repositories. As far as being unwilling to explain your use case, it sounds like you already know it's a bad use case. Explaining it could result in people suggesting a better way to handle whatever you are trying to do. – Ilion Apr 21 '18 at 03:38

1 Answers1

0

What you're doing here runs literally counter to and flies in the face of the very point of a distributed version control system. What you and your team are looking for is software to help manage your repository and allow for you and your team to easily clone and publish changes to it.

Depending on what you're looking for, you can leverage:

  • Gitolite is free and can be configured more straightforwardly with permissions.
  • GitHub always exists as an option; you can buy a private repository workspace and have all of your developers publish there.

Your use case describes the want of a build system (like Jenkins), but that's not germane to the main thrust of your main question.

Makoto
  • 104,088
  • 27
  • 192
  • 230
  • I've seen it said asking good questions is an art, and I guess I'm at the finger-painting level. What part of my question led you to this conclusion? I've got many repositories cloned for this process, from github and gerrit remotes. All changes are upstreamed. The issue is that cloning, building, and especially setting up the environment is arduous. Given the linked solutions for Linux, I was asking if there was something comparable for my environment. The upvotes on the other questions led me to think this was not an inherently wrong thing to try. – Brett Stottlemyer Apr 22 '18 at 17:42
  • Your initial question (sans context) referred to the basic process of cloning, committing and publishing to a remote Git repository. It sounded like you needed something to manage *that*. If your question is solely about your build process, I encourage you to delete *this* question and ask about it. But before you do that I would encourage you to research build automation tools like Jenkins which sound like they would do exactly what you're looking for. – Makoto Apr 22 '18 at 17:55
  • 1
    You've clearly lumped this into the xy-problem category (which may be appropriate). But at some point, doesn't pragmatism come into play? Is it not reasonable to at least ask about using git in an unorthodox way instead of doing a reset on a working build process? FYI, we already are using jenkins, but I assert you can't automate something you can't run manually, so a manual build has to come first. That is what this environment is for, the final tweaks to make sure the integration of all of the pieces works correctly. – Brett Stottlemyer Apr 22 '18 at 18:26