On Mon, 29 Apr 2013 09:50:07 -0700 (PDT)
David Cherian <david.cher...@gmail.com> 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

1) Each developer must fetch/pull only via a named remote (say,
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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to