From: "Matthieu Moy" <Matthieu.Moy@xxxxxxxxxxxxxxx>
Jordan DE GEA <jordan.de-gea@xxxxxxxxxxxxxxxx> writes:
Matthieu Moy <matthieu.moy@xxxxxxxxxxxxxxx> 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@xxxxxxx> 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.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html