"Philip Oakley" <philipoakley@xxxxxxx> writes: > From: "Matthieu Moy" <Matthieu.Moy@xxxxxxxxxxxxxxx> > >> 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) Yes, but again, the point of this thread is to document *one* workflow, not all possible uses of pushRemote. It's much easier to describe "one typical triangular workflow" in a concrete way than to try to be completely general and end up with a description that average users would just not understand. It would be different to me if we were writting the pushRemote part of config.txt, where we have to be as general as possible. -- 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