Re: [PATCH 2/2] Triangular workflow

[Martin Ågren]

On 17 November 2017 at 17:07, Daniel Bensoussan
 wrote:
> The documentation about triangular workflow was not clear enough.

I think you would be able to `git rebase -i` these two patches into a
single, perfect patch. ;-) Maybe in collaboration with Albertin?

> -===
> -`git config push.default current`
> -===
> +
> +`git clone `
> +`git remote add **PUBLISH**`
> +`git push`
> +

This renders as a single line for me, including "**PUBLISH**". (I use
AsciiDoctor, does this look good with AsciiDoc, I wonder?)

I've never worked with triangular workflows. That means I can't judge
the correctness of this, but what I've read seems reasonable and
helpful. I dropped some comments along the way, I hope you'll find them
constructive.

Martin

[PATCH 2/2] Triangular workflow

[Daniel Bensoussan]

The documentation about triangular workflow was not clear enough.
So it couldn't be clear enough for someone else. That's why we decided to
change it. Some documentation about triangular workflow already exists.
However, it seems unfortunate that there is no documentation about it in Git.

Based-on-patch-by: Jordan DE GEA 
Signed-off-by: Michael Haggerty 
Signed-off-by: Jordan DE GEA 
Signed-off-by: Matthieu Moy 
Signed-off-by: Timothee Albertin 
Signed-off-by: Nathan Payre 
Signed-off-by: Daniel Bensoussan 
---
 Documentation/gitworkflows.txt | 59 +++---
 1 file changed, 26 insertions(+), 33 deletions(-)

diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 3f1ddba82..4aea16bc0 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -490,7 +490,7 @@ GitHub or GitLab which provide a dedicated mechanism for 
requesting merges.
 
 --   -
 | UPSTREAM   |  maintainer   | PUBLISH   |
-|  git/git   |- - - - - - - -|  me/remote|
+||- - - - - - - -|   |
 --  <-   -
   \ /
\   /
@@ -515,7 +515,7 @@ new and the old code, and then send it to a maintainer to 
commit
 and push it.  This isn't convenient at all, neither for the
 contributor, neither for the maintainer. With the triangular
 workflow, the contributors have the write access on **PUBLISH**
-so they don't have to pass upon maintainer(s).  And only the
+so they don't need maintainer(s) approval to write code.  And only the
 maintainer(s) can push from **PUBLISH** to **UPSTREAM**.
 This is called a distributed workflow (See "DISTRIBUTED WORKFLOWS"
 above).
@@ -526,13 +526,13 @@ The goal of the triangular workflow is also that the rest 
of the
 community or the company can review the code before it's in production.
 Everyone can read on **PUBLISH** so everyone can review code
 before the maintainer(s) merge it to **UPSTREAM**.  It also means
-that, in a free software, anyone can propose code without danger
+that, in free software, anyone can propose code without danger
 for the stability of the software.
 
 * Encourages clean history by using `rebase -i` and `push --force` to
 the public fork before the code is merged.
 
-This is just a side-effect of the "review before merge" mentionned
+This is just a side-effect of the "review before merge" mentioned
 above but this is still a good point.
 
 
@@ -543,18 +543,20 @@ workflow.
 Preparation as a contributor
 
 
-Cloning from **PUBLISH**, which is a fork of **UPSTREAM** or an empty
-repository.
+Cloning from **UPSTREAM**.
 
 ==
-`git clone `
+`git clone `
 ==
 
-Setting the behavior of push for the triangular workflow:
+If **PUBLISH** doesn't exist, a contributor can publish his own repository.
+**PUBLISH** contains modifications before integration.
 
-===
-`git config push.default current`
-===
+
+`git clone `
+`git remote add **PUBLISH**`
+`git push`
+
 
 Adding **UPSTREAM** remote:
 
@@ -576,12 +578,6 @@ Example with master as :
 * `git config branch.master.pushRemote origin`
 ===
 
-Staying up-to-date
-~~
-
-Retrieve updates from **UPSTREAM** with `git pull` and send them to
-**PUBLISH** with `git push`.
-
 Making your work available
 ~~
 
@@ -590,20 +586,19 @@ the **UPSTREAM** thanks to the configuration you did 
earlier with the
 `git config remote.pushdefault origin` command.
 
 When a contributor pushes something, the `git config push.default
-current` command can be used to specifies that the name of the
+current` command can be used to specify that the name of the
 **PUBLISH** branch is the same as the name of the **LOCAL** one.
 
-.Display the push remote's name:
+.Display the name of the push remote:
 [caption="Recipe: "]
 
-=
-`git rev-parse --abbrev-ref @{push}`
-=
-
 The shorthand `@{push}` denotes the remote-tracking branch
 where the  would be pushed to. If no  is specified
 (`@{push}`),  takes the value of the current branch.
 
+=
+`git rev-parse --abbrev-ref @{push}`
+=
 
 .Display the fetch remote's name:
 [caption="Recipe: "]
@@ -630,6 +625,12 @@ takes the value of the current branch.
 `git log @{push}..`
 
 
+Staying up-to-date
+~~
+