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

From: Matthieu Moy <[email-masked]>
Date: Mon, 06 Jun 2016 09:58:51 +0200

Jordan DE GEA <[email-masked]> writes:

>> Matthieu Moy <[email-masked]> a écrit :
>> 
>> That is technically correct, but to illustrate the overall flow, I'd
>> rather avoid naming the repositories in terms of git commands. If you do
>> so, you will probably end up with tautological explanations like this
>> later in the text: "FETCH_REMOTE is the remote from where you fetch,
>> PUSH_REMOTE is the remote to which you push, and LOCAL is local".
>> 
>> I suggested PUBLIC-FORK earlier, and didn't get any feedback on it. I
>> think it translates the intent better than PUSH_REMOTE. An alternative
>> would be PUBLISH (= the repository you use to publish your changes so
>> that the maintainer can pick them).
>
>> "Philip Oakley" <[email-masked]> writes:
>> However your gitster/git repo feels like it would match the me/git
>> viewpoint, in that while it is 'open', it isn't really a formal
>> publishing place. Certainly I don't think that I 'publish' what's in
>> my personal github repos, which I use as an open backup (and any
>> PR's I put to the G4W project repo are referenced from there).
>
>
> For Philip Oakley, PUBLISH seems to not be a good name. 
> For PUBLIC-FORK, a fork can be private so I think that’s not a good idea. 

I don't think you will find a name that fits all use-cases. IHMO, best
is to pick one rather general use-case, make the explanations for it,
and maybe explain somewhere that there are variants.

If the fork is completely private, then your diagram with a "maintainer"
arrow from it to upstream is not valid. It needs at least to be visible
to the maintainer. "public" may be a bit strong as you don't need to
make it "public" to everyone on earth, but to me that's OK to describe
the use-case.

> As the third-place is the repository used to work on commits/patches, 
> a simple name can be WORK_REPOSITORY.

"WORK" is already used to describe "worktree" which is precisely not
this repository. I don't "work" on my public fork, I "work" locally and
then just send commits there.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/