mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Timothee Albertin <>
	Timothee Albertin <>,
	Michael Haggerty <>,
	Matthieu Moy <>,
	Daniel Bensoussan <>,
	Nathan Payre <>
Subject: Re: [PATCH] doc: clarify triangular workflow
Date: Sat, 02 Dec 2017 22:36:41 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Timothee Albertin's message of "Thu, 30 Nov 2017 10:42:12 +0100")

Timothee Albertin <> writes:

> diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
> index 02569d0..21f6dc8 100644
> --- a/Documentation/gitworkflows.txt
> +++ b/Documentation/gitworkflows.txt
> @@ -407,8 +407,8 @@ follows.
>  `git pull <url> <branch>`
>  =====================================
> -Occasionally, the maintainer may get merge conflicts when he tries to
> -pull changes from downstream.  In this case, he can ask downstream to
> +Occasionally, the maintainers may get merge conflicts when they try to
> +pull changes from downstream.  In this case, they can ask downstream to
>  do the merge and resolve the conflicts themselves (perhaps they will
>  know better how to resolve them).  It is one of the rare cases where
>  downstream 'should' merge from upstream.

The document starts with

    This document attempts to write down and motivate some of the
    workflow elements used for `git.git` itself.  Many ideas apply
    in general, though the full workflow is rarely required for
    smaller projects with fewer people involved.

and makes me wonder (note: I am not involved in writing any of the
existing text in this document) how much material foreign to the
actual workflow used for `git.git` should go in here.  Having
multiple maintainers at the same time is not a workflow element that
we have ever used, for example, so I am not sure about the change in
the above paragraph.

> +-------------------

I really hate to say this.  Before I made comment on the last round
that tried to add this section, I didn't read the original closely

The thing is, it does already cover the triangular workflow in the
"Merge workflow" section (you may need to already know what you are
reading to realize that fact, though).  The text in the existing
"Merge workflow" section where requestor pushes to somewhere for the
maintainer to pull from may not be immediately obvious, and it may
be worthwhile to improve it, but I find it highly misleading to add
an entirely new section as if it is describing yet another separate
workflow that is different from anything that is already described
in the document.  It is not.

A replacement of the entire section (but I'd recommend keeping the
"Merge workflow" title, which contrasts well with the other "Patch
workflow" that follows), or a separate document that is referred to
with "see that other one for a lengthier description" by the
existing "Merge workflow" section, or somewhere in between, might be
a more acceptable organization, though.

  reply	other threads:[~2017-12-03  6:36 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 [this message]
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
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).