ALBERTIN TIMOTHEE p1514771 <timothee.albertin@xxxxxxxxxxxxxxxxx> writes: >>>> +This workflow is commonly used on different platforms like BitBucket, >>>> +GitHub or GitLab which provide a dedicated mechanism for requesting merges. >>> >>> As a user, I find it terribly frustrating when reading documentation >>> telling me that "there's a dedicated mechanism" for something without >>> telling me actually how to do it. > >>Also I think the description is backwards from end-user's point of >>view. It's not that it is common to use the workflow on these >>hosting sites. It's more like people use the workflow and adopt use >>of these hosting sites as one building block of the workflow. > > I'm wondering if this sentence is really useful. It's not essential > and it will take lot of time and space to talk about it properly. > So, if you agree, we'll erase it. I think it is useful. My guess is that most people don't know the wording "triangular workflow", but most people know about GitHub for example. See e.g. https://trends.google.com/trends/explore?q=%22triangular%20workflow%22,github,gitlab,bitbucket So the hope here is that the reader reading this feels "Ah, OK, this is about how to do pull-requests on GitHub". OTOH, I wouldn't like a Git official documentation to be biaised towards a single hosting site. > In the case of a triangular workflow, if the project already exists, > PUBLISH will already exist too. No. If the project already exists, then UPSTREAM exists, and the contributor will create his or her own PUBLISH. There's generally two ways to do it: * On platforms supporting this, use the platform's mechanism to create a fork (e.g. fork button on GitHub/GitLab's web UI). * One can create an empty PUBLISH, clone UPSTREAM, and push to PUBLISH. -- Matthieu Moy https://matthieu-moy.fr/
