Re: [RFC/PATCHv2] Documentation: triangular workflow

> Jordan DE GEA <jordan.de-gea@grenoble-inp.org> writes:
>
>> +TRIANGULAR WORKFLOW
>> +-------------------
>> +
>> +In some projects, you cannot push directly to the project but have to
>> +suggest your commits to the maintainer (e.g. pull requests).
>> +For these projects, it's common to use what's called a *triangular
>> +workflow*:
>> +
>> +- Taking the last version of the project by fetching (e.g.
>> +  **UPSTREAM**)
>> +- Writing modifications and push them to a fork (e.g. **PUBLIC-FORK**)
>> +- Opening a pull request
>> +- Checking of changes by the maintainer and, merging them into the
>> +  **UPSTREAM** repository if accepted
>> +
>> +
>> +........................................
>> +------------------               -----------------
>> +| UPSTREAM       |  maintainer   | PUBLIC-FORK   |
>> +|  git/git       |- - - - - - - -|  me/remote    |
>> +------------------       ←       -----------------
>> +              \                     /
>> +               \                   /
>> +          fetch↓\                 /↑push
>> +                 \               /
>> +                  \             /
>> +                   -------------
>> +                   |   LOCAL   |
>> +                   -------------
>> +........................................
>
> I agree with other commenters that "PUBLIC-FORK" is a name that does
> not capture the essense of the triangular being the next step
> forward, compared to the "central shared repository" workflow, to
> take advantage of the distributed nature of Git.
>
> "Where you push so that somebody else can fetch from there" does not
> have to be public.  You may be submitting a course assignment there,
> only to be seen by your professor but not by others in the class.
> Also, you do not your call "LOCAL" a "LOCAL-FORK" and that is a good
> thing.  In a distributed world, everything is a fork, so adding
> "-FORK" to a name is pretty much meaningless.
>
> So neither "PUBLIC" nor "FORK" in "PUBLIC-FORK" is a good word to
> describe this thing.
>
> The only reason you are pushing there is because your "LOCAL" is
> either not accessible from outside world, and/or you do not want to
> give a direct access to it (otherwise you could have allowed an
> access to whoever is going to fetch from you direct access to
> "LOCAL" and be done with it without creating "PUBLIC-FORK").
>
> That is why I reminded that we earlier in the design phase called
> this "publish"; it is a place you give access to others a selected
> work of yours that you choose to give them access to.

> Whether you
> are a leaf contributor, a student who got stuck and wants to ask
> suggestions from your friends after looking your code over, or an
> integrator of a big public project, I would view the act to push
> into such a place you give selective visibility to your work to
> others as publishing your work.