git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[RFC/PATCHv2] Documentation: triangular workflow

From
JGJordan DE GEA <jordan.de-gea@grenoble-inp.org>
Date
Jun 6, 2016, 09:48 UTC
Message-ID
<1465206518-1780-1-git-send-email-jordan.de-gea@grenoble-inp.org>
In-Reply-To
<1464697717-5751-1-git-send-email-jordan.de-gea@grenoble-inp.org>

Currently, triangular workflow can be configured, but there is no documentation about it. A documentation is useful to keep configuration possibilities up-to-date.

A new subsection is created in gitworkflow.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Jordan DE GEA <jordan.de-gea@grenoble-inp.org>
---
Changes since version 1:
 - content moved in gitworktree
 - content improved
 Documentation/gitworkflows.txt | 155 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 155 insertions(+)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index f16c414..cd77893 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -463,6 +463,157 @@ if you get conflicts: `git am -3` will use index information contained
 in patches to figure out the merge base.  See linkgit:git-am[1] for
 other options.
 
+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   |
+                   -------------
+........................................
+
+Git options to use:
+~~~~~~~~~~~~~~~~~~~
+ - `branch.<branch>.remote`
+ - `branch.<branch>.pushRemote`
+ - `remote.pushDefault`
+ - `push.default`
+
+See linkgit:git-config[1].
+
+Push behaviour
+~~~~~~~~~~~~~~
+
+Setting the behavior of push for the triangular workflow:
+
+===========================
+* `git config push.default current`
+===========================
+
+
+Case 1: LOCAL is a clone of **PUBLIC-FORK**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'In this case, the remote named `origin` corresponds to **PUBLIC-FORK**.'
+
+Adding **UPSTREAM** remote:
+
+===================================
+* `git remote add upstream <UPSTREAM_url>`
+===================================
+
+Setting `branch.<branch>.remote` and `branch.<branch>.pushRemote` in
+order to:
+
+ - pull from **UPSTREAM** without argument for pull
+ - push to **PUBLIC-FORK** (`origin`) without argument for push
+
+Example with master as <branch>:
+===================================
+* `git config branch.master.remote upstream`
+* `git config branch.master.pushRemote origin`
+===================================
+
+Case 2: LOCAL is a clone of **UPSTREAM**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'In this case, the remote named `origin` corresponds to
+**UPSTREAM**.'
+
+Adding **PUBLIC-FORK** remote:
+
+===================================
+* `git remote add public_fork <PUBLIC-FORK_url>`
+===================================
+
+**Method 1: One option for all branches**
+
+Setting `remote.pushDefault` in order to push to **PUBLIC-FORK** without
+argument for push.
+
+===================================
+* `git config remote.pushDefault public_fork`
+===================================
+
+**Method 2: Each branch its option**
+
+Setting `branch.<branch>.pushRemote` in order to push to **PUBLIC-FORK**
+without argument to push.
+
+Example with master as <branch>:
+===================================
+* `git config branch.master.pushRemote public_fork`
+===================================
+
+
+Stay up-to-date
+~~~~~~~~~~~~~~~
+
+Retrieving updates from **UPSTREAM** with `git pull` and sending
+them to **PUBLIC-FORK** with `git push`.
+
+Checks
+~~~~~~
+
+Uses of command line shorthand `@{push}` and `@{upstream}`.
+
+**Display the push remote's name: **
+
+===================================
+* `git rev-parse --abbrev-ref '@{push}'`
+===================================
+
+The shorthand `<branch>@{push}` denotes the remote-tracking branch
+where the <branch> would be pushed to. If no <branch> is specified
+(`@{push}`), <branch> takes the value of the current branch.
+
+See linkgit:git-rev-parse[1].
+
+**Display the fetch remote's name: **
+
+===================================
+* `git rev-parse --abbrev-ref '@{upstream}'`
+===================================
+
+The shorthand "<branch>@{upstream}" substitutes the name of the
+"upstream" of the branch. If no <branch> is specified (`@{upstream}`),
+<branch> takes the value of the current branch.
+
+**Display commits added to the current branch since last push: **
+
+===============
+* `git log @{push}..`
+===============
+
+See linkgit:git-log[1].
+
+**Display commits added to a specific branch since last push: **
+
+==============================
+* `git log <branch_name>@{push}..`
+==============================
 
 SEE ALSO
 --------
@@ -474,6 +625,10 @@ linkgit:git-rebase[1],
 linkgit:git-format-patch[1],
 linkgit:git-send-email[1],
 linkgit:git-am[1]
+linkgit:git-config[1],
+linkgit:git-log[1],
+linkgit:git-rev-parse[1]
+
 
 GIT
 ---
-- 
2.7.4 (Apple Git-66)
Previous: Philip OakleyNext: Junio C Hamano
Message 24 of 41 in “[RFC] Triangular Workflow: user friendly full implementation”
  1. Jordan DE GEAMay 26, 2016
  2. Matthieu MoyMay 26, 2016
  3. Junio C HamanoMay 26, 2016
  4. [RFC] Triangular Workflow UI improvementJordan DE GEA, May 30, 2016
  5. Philip OakleyMay 27, 2016
  6. [RFC] Triangular Workflow UI improvmentsJordan DE GEA, May 30, 2016
  7. Triangular Workflow UI improvement: DocumentationJordan DE GEA, May 31, 2016
  8. Matthieu MoyMay 31, 2016
  9. Jordan DE GEAJun 1, 2016
  10. Michael HaggertyJun 2, 2016
  11. Philip OakleyJun 3, 2016
  12. Jordan DE GEAJun 3, 2016
  13. Matthieu MoyJun 3, 2016
  14. Jordan DE GEAJun 3, 2016
  15. Jordan DE GEAJun 5, 2016
  16. Matthieu MoyJun 6, 2016
  17. Philip OakleyJun 6, 2016
  18. Matthieu MoyJun 6, 2016
  19. Philip OakleyJun 6, 2016
  20. Matthieu MoyJun 7, 2016
  21. Philip OakleyJun 7, 2016
  22. Junio C HamanoJun 3, 2016
  23. Philip OakleyJun 3, 2016
  24. [RFC/PATCHv2] Documentation: triangular workflowJordan DE GEA, Jun 6, 2016
  25. Junio C HamanoJun 6, 2016
  26. Philip OakleyJun 6, 2016
  27. Matthieu MoyJun 7, 2016
  28. Jordan DE GEAJun 7, 2016
  29. [PATCHv3] Documentation: triangular workflowJordan DE GEA, Jun 7, 2016
  30. Junio C HamanoJun 7, 2016
  31. Jordan DE GEAJun 8, 2016
  32. Matthieu MoyJun 8, 2016
  33. [PATCHv4] Documentation: triangular workflowJordan DE GEA, Jun 9, 2016
  34. Junio C HamanoJun 9, 2016
  35. Ramkumar RamachandraJun 11, 2016
  36. Philip OakleyJun 11, 2016
  37. Philip OakleyJun 9, 2016
  38. Junio C HamanoJun 10, 2016
  39. Philip OakleyJun 11, 2016
  40. Junio C HamanoJun 13, 2016
  41. [RFC] Triangular Workflow UI improvementJordan DE GEA, May 30, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.