On 5/20/20 4:38 PM, andy pugh wrote:
On Wed, 20 May 2020 at 08:29, John Morris <j...@zultron.com> wrote:
(B) Some changes going into mainline branches are not going through PRs.
If this is not a deliberate decision and the situation evolved
organically from the days of glo, the project should consider requiring
all changes go through a submit/CI/review/merge workflow enforced by
GH's branch protection rules.
What is the workflow for that? It seems to require a feature branch to
be created for every commit?
Or, alternatively, you need to keep your own fork and the main repo on
your local machine, and keep them in synch?
(And I find it difficult to keep my own fork on github synched with
the main linuxcnc repo, and the various clones that I have scattered
through my development systems)
I suspect that this is just a problem with my git-fu. How can one do
this without an infinite proliferation of feature branches?
A problem with feature branches is that they go stale, too. Keeping
them up to date and mergable could become a tedious housekeeping task.
In general, there wouldn't be much difference in anyone's development
workflow, except for instead of directly pushing changes to mainline
branches (`master`, `2.8`, `2.7`), one submits a PR instead. It looks
like this happens a lot (even most?) of the time already.
You don't need to change your feature branch workflow, and of course you
can manage those however you like. It's only when you're ready to merge
your feature branch into mainline that the "all contributions must go
through a PR" requirement applies.
Did I understand and answer your question well enough? Thanks-
John
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
