| Re: [jdt-dev] Github workflow |
Thomas,
I was just experimenting with this exact thing for that latest
PDE repo renaming changes I was doing.
So I have the following similar to what you suggested here:
This way I leave master linked to the "real" repository (using the origin remote). When I create a branch for my PR I commit it and then I pushed it to the "merks" remote. Then I can switch back to master anytime (as I did above) and pull (from origin), so I don't need to keep my fork's master in sync this way. Just like what you are suggesting. I think this approach seems less painful (to me) than what's currently outlined, which I think is copied from here:
https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md
It will also be nice if we don't end up with many diverged copies
of this documentation so we don't have to change it in multiple
places as it evolves...
Regards,
Ed
Hi folks,
I've been reviewing https://github.com/eclipse-jdt/.github/blob/main/CONTRIBUTING.md and I have a couple of suggestions about our github development flow:
1. I suggest recommend a simpler fork/pull workflow. My setup is like this:
fork eclipse-jdt/eclipse.jdt.uiclone eclipse-jdt/eclipse.jdt.uigit remote add thomas .../tsmaeder/eclipse.jdt.ui
This way, branches are set up to track eclipse-jdt/eclipse.jdt.ui, not my fork. I never have to sync the fork, it purely exists to house my branches used in PR's. I always pull from the main repo.
2. We should set up a codeowners file that suggests reviewers for new PR's: many changes in gerrit got lost because no-one was requested.3. We should set up a PR template that explains what we expect in a PR. Links to docs pages are fine.4. Should we require an approval before merging?5. Commit messages: now that we can have multiple commits in a PR, using the bug title as the commit message does not make sense to me. I would much rather have a concise description of the change. Look at this one, for example: https://bugs.eclipse.org/bugs/show_bug.cgi?id=577109 I doubt "[postfix] assist "sif" gone wild " is a very helpful commit message. Including a bug number for fixes is still helpful, though. Note that there is tooling in Github that allows you to find the PR a change was introduced in. So if you really need to know the history of a change....6. Do we expect/recommend people to sign their commits with gpg?7. Unless we have a technical reason not to, I would recommend we protect the master branch against direct pushes. PR's only.
discuss ;-)
/Thomas
_______________________________________________ jdt-dev mailing list jdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev