On Wed, 20 Jul 2016 07:41:52 -0700 (PDT)
Sanjiv Kumar <devopsarchitect...@gmail.com> 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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to