On Wed, 20 Jul 2016 07:41:52 -0700 (PDT) Sanjiv Kumar <[email protected]> wrote:
[...] > I am looking for inputs and suggestions on the following workflow: > > 1. Can we do the contributions stuff in public repo using > stash/bitbucket? I think we can do it using forking and pull. This question is irrelevant to Git: Git-as-a-software-package allows two ways of "getting stuff from the outside": * Fetching data from a remote Git repository and then merging it into the local one. * Applying textual patches. Basically, what most folks know as "pull request" these days is some feature in the web interface of certain Git hosting providers which allows a developer to nominate a branch of their choice in one of their repos to be considered by the upstream developers for inclusion (merging) into their original repository. Not too many people know that the stock Git actually includes the `git request-pull` command which allows the developer to prod the devs of the upstream project with the informaition necessary for them to obtain, inspect and integrate the changes done against the upstream projects. In a sense, what Github et al offer in this venue is slightly modified and web-ified solution which does not change the essense of the matter: Git is able to grab the specified history from any remote repository and integrate it into a local one. So, yes. > 2. Can we sync the two repos (private and public) unidirectional and > bidirectional? This we will decide later on if we need to implement > unidirectional or bidirectional. I'm afraid of the word "sync"; I hope this is just an unfortunately selected term. Synchronizing means you have two pieces of information and either make one of them a complete replica of the other (one-way sync) or somehow make each of them contain all the data the other one has, plus its own. While the first one is simple with Git (but IMO has no sense outside of making backups) the second one is not -- starting right with the need to have exact semantics of such sync up front before attempting to implement it. On the other hand, if you drop this "sync" bit, you get the model everyone uses :-) Basically your public repo in this model only ever receives specific updates from your internal repos. You push what you deem is OK for publishing, and on a schedule you deem as appropriate. Having a proper mental model for a public repository in a world of distributed CM systems requires certain mindset; for me, [1] was an eye-opener, so I recommend you to read it and understand what it talks about. This explanation is for much larger scale Git deployment that you seem to be envisioning, but this is exactly what helps to grasp the ideas behing public vs private repositories. 1. http://lwn.net/Articles/246381/ -- 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/d/optout.
