On Mon, 29 Apr 2013 09:50:07 -0700 (PDT) David Cherian <[email protected]> wrote:
> I have several tool repositories using git, and have several users > who can develop on several of these tool repos. What I would like to > do is have a way of preventing users from accidentally pulling the > wrong repo into the repo they are working on. > > Does git have a mechanism to do this? Has anyone else encountered > this issue? > > In Bitkeeper, you could create a repo with a unique ID, and Bitkeeper > inherently would check the Repo ID and would prevent a pull from > happening if the repo id did not match. > > I am startled with the fact that I can pull two completely different > repos into each other. But this is one of fundamental design decisions in Git: that you can fetch data from any repository you want. And really I think you're startled by this "problem" for no reason: if a developer pulled from a wrong repo, they will most probably just get a merge conflict or no conflict but a weirdly looking tree, and in either case this situation could be rolled back by doing git reset --hard HEAD^ And if your developer thought they were a Git ninja and did rebasing pull, then the pre-pull situation could have been restored by doing git reset --hard ORIG_HEAD Git data model is simple, and brinding history from a wrong repo does not incur anything special to the receiving repo apart from temporarily wasting the disk space it occupies. You might argue that the said developer might not notice the problem created by pulling from a wrong repo but I should say your developers must not be idiots: they should a) think about what they are doing, b) check the results of their actions, and c) know their ways to recover, if needed (or be trained to promptly call your local Git goto person for assistance). In any case, I think your difficulty might be addressed with a simple policy: 1) Each developer must fetch/pull only via a named remote (say, "origin"). 2) In each local repository a developer has, such a named remote must be initialized to point to whatever remote repository it's supposed to communicate with. If you have a network of repositories (so that each developer might fetch from different remote repositories keeping the same project but maintained by different developers) then create a number of named remotes (and name them after the fellow developers, for instance). -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
