Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation
- From
Philip Oakley <philipoakley@iee.org>
- Date
- Jun 6, 2016, 16:46 UTC
- Message-ID
- <A8FD6EF510F149A4A05FE553BEDD8511@PhilipOakley>
- In-Reply-To
- <vpq7fe2rbno.fsf@anie.imag.fr>
From: "Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>
Show 32 quoted lines
> 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.
That's only true for a Pull Request workflow. For a Patch workflow (such as Git) the user's home vault can be completely private.
Show 20 quoted lines
> 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/ > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >