mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Matthieu Moy <>
Cc: Junio C Hamano <>,
	"git\" <>,
	Michael Haggerty <>,
	Jordan DE GEA <>,
	PAYRE NATHAN p1508475 <>
Subject: Re: [PATCH v2] doc: add triangular workflow
Date: Fri, 15 Dec 2017 17:04:57 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (ALBERTIN TIMOTHEE's message of "Fri, 15 Dec 2017 15:46:47 +0000")

ALBERTIN TIMOTHEE p1514771 <> 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.,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.


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

  parent reply	other threads:[~2017-12-15 16:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-30  9:42 [PATCH] doc: clarify triangular workflow Timothee Albertin
2017-12-03  6:36 ` Junio C Hamano
2017-12-07  9:26   ` BENSOUSSAN--BOHM DANIEL p1507430
     [not found]   ` <>
2017-12-07 12:43     ` Matthieu Moy
2017-12-07 15:31       ` Junio C Hamano
2017-12-14 10:48 ` [PATCH v2] doc: add " Daniel Bensoussan
     [not found] ` <>
2017-12-14 15:04   ` Matthieu Moy
2017-12-14 20:47     ` Junio C Hamano
2017-12-15 15:46       ` ALBERTIN TIMOTHEE p1514771
     [not found]       ` <>
2017-12-15 16:04         ` Matthieu Moy [this message]
2017-12-15 15:18     ` ALBERTIN TIMOTHEE p1514771
     [not found]     ` <>
2017-12-15 15:54       ` Matthieu Moy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).