Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation

["Philip Oakley" <philipoakley@iee.org>]

From: "Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> From: "Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>
>>
>>> But then the maintainer is not the one picking changes from it (you're
>>> sending them by email), so the "maintainer" label is not really accurate
>>> in the diagram:
>>>
>>> +------------               -----------
>>> +| UPSTREAM |  maintainer   | ORIGIN  |
>>> +|  git/git |- - - - - - - -|  me/git |
>>> +------------       ←       -----------
>>> +         \                   /
>>> +          \                 /
>>> +     fetch↓\               /↑push
>>> +            \             /
>>> +             \           /
>>> +             -------------
>>> +             |   LOCAL   |
>>> +             -------------
>>>
>> Ahh, that's a useful clarification. I use my git repo both for the G4W
>> (which does take pull requests) and for Junio's Git.
>>
>> The use of the 'home-vault' fork as being for
>> (a) backup,
>> (b) open viewing, and
>> (c) sending pull requests
>> are subtle distinctions for the naming (of both the forked repo, and
>> the workflow).
>>
>> It's probably even worse in a corporate environment as to how personal
>> the personal home vault is, as compared to just having a namespace in
>> a centralised dev server/repo. (the question of how to make such
>> arrangements seems to come up moderately often on the various lists)
>
> Yes, but again, the point of this thread is to document *one* workflow,

I'd agree here.

> not all possible uses of pushRemote. It's much easier to describe "one
> typical triangular workflow" in a concrete way

That *one* workflow would be a _specific_ flow - I'm reading 'typical' as
implying common/general workflow(s), which may not be what you hoped to
convey.

>   than to try to be
> completely general and end up with a description that average users
> would just not understand.

I do think that the description of the one specific flow should include the
clarifications that discriminate it from other, potentially mistakenly
confused with this one, flows. It would be that disambiguation that would
clear up the misunderstanding.

>
> It would be different to me if we were writting the pushRemote part of
> config.txt, where we have to be as general as possible.

As an aside, the discussion has indicated that the documentation may be a
bit light on describing (and referencing) how multi-user server set-ups can
be arranged to faciltate (or may hinder) the different flows.
--
Philip
(mail delayed by lack of wifi)