From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: Jordan DE GEA <jordan.de-gea@grenoble-inp.org>
Cc: Philip Oakley <philipoakley@iee.org>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org,
Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org>,
Samuel Groot <samuel.groot@grenoble-inp.org>,
Tom Russello <tom.russello@grenoble-inp.org>
Subject: Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation
Date: Mon, 06 Jun 2016 09:58:51 +0200 [thread overview]
Message-ID: <vpq7fe2rbno.fsf@anie.imag.fr> (raw)
In-Reply-To: <F57B7CD2-8F8B-4D58-B145-285E69F9B4BE@grenoble-inp.org> (Jordan DE's message of "Sun, 5 Jun 2016 23:28:34 +0200")
Jordan DE GEA <jordan.de-gea@grenoble-inp.org> writes:
>> Matthieu Moy <matthieu.moy@grenoble-inp.fr> 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" <philipoakley@iee.org> 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/
next prev parent reply other threads:[~2016-06-06 7:59 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-26 10:06 [RFC] Triangular Workflow: user friendly full implementation Jordan DE GEA
2016-05-26 11:04 ` Matthieu Moy
2016-05-26 18:30 ` Junio C Hamano
2016-05-30 8:46 ` [RFC] Triangular Workflow UI improvement Jordan DE GEA
2016-05-27 7:32 ` [RFC] Triangular Workflow: user friendly full implementation Philip Oakley
2016-05-30 9:07 ` [RFC] Triangular Workflow UI improvments Jordan DE GEA
2016-05-31 12:28 ` [RFC/PATCH] Triangular Workflow UI improvement: Documentation Jordan DE GEA
2016-05-31 14:33 ` Matthieu Moy
2016-06-01 9:32 ` Jordan DE GEA
2016-06-02 12:02 ` Michael Haggerty
2016-06-03 7:25 ` Philip Oakley
2016-06-03 9:52 ` Jordan DE GEA
2016-06-03 11:36 ` Matthieu Moy
2016-06-03 11:53 ` Jordan DE GEA
2016-06-05 21:28 ` Jordan DE GEA
2016-06-06 7:58 ` Matthieu Moy [this message]
2016-06-06 16:46 ` Philip Oakley
2016-06-06 16:54 ` Matthieu Moy
2016-06-06 19:21 ` Philip Oakley
2016-06-07 7:03 ` Matthieu Moy
2016-06-07 20:08 ` Philip Oakley
2016-06-03 15:46 ` Junio C Hamano
2016-06-03 22:16 ` Philip Oakley
2016-06-06 9:48 ` [RFC/PATCHv2] Documentation: triangular workflow Jordan DE GEA
2016-06-06 19:23 ` Junio C Hamano
2016-06-06 22:21 ` Philip Oakley
2016-06-07 6:58 ` Matthieu Moy
2016-06-07 8:02 ` Jordan DE GEA
2016-06-07 8:38 ` [PATCHv3] " Jordan DE GEA
2016-06-07 19:12 ` Junio C Hamano
2016-06-08 8:37 ` Jordan DE GEA
2016-06-08 13:20 ` Matthieu Moy
2016-06-09 12:35 ` [PATCHv4] " Jordan DE GEA
2016-06-09 17:02 ` Junio C Hamano
2016-06-11 15:58 ` Ramkumar Ramachandra
2016-06-11 19:31 ` Philip Oakley
2016-06-09 18:19 ` Philip Oakley
2016-06-10 16:47 ` Junio C Hamano
2016-06-11 19:25 ` Philip Oakley
2016-06-13 18:35 ` Junio C Hamano
2016-05-30 8:39 ` [RFC] Triangular Workflow UI improvement Jordan DE GEA
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpq7fe2rbno.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp.fr \
--cc=erwan.mathoniere@grenoble-inp.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jordan.de-gea@grenoble-inp.org \
--cc=philipoakley@iee.org \
--cc=samuel.groot@grenoble-inp.org \
--cc=tom.russello@grenoble-inp.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.