From: "Matthieu Moy" <Matthieu.Moy@xxxxxxxxxxxxxxx>
"Philip Oakley" <philipoakley@xxxxxxx> writes:
From: "Matthieu Moy" <Matthieu.Moy@xxxxxxxxxxxxxxx>
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.
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)
Philip
--
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