| Re: [platform-dev] Github workflow |
_______________________________________________Wim,
Note though my comment about a commit related to an issue from a different repository. Given the plethora of repositories that comprise the Eclipse SDK, that seems not at all unlikely to happen, is it? Or should that be forbidden? Or should we not have rules at all? We do seem to have several proposed workflows but not really general agreement on what should or shouldn't be done nor how it should be done...
Regards,
Ed
On 22.03.2022 13:00, Wim Jongman wrote:
Ed, in time EGit will probably learn how to interpret GitHub-related content as it can now do for Bugzilla. For issues spanning repositories, it would indeed be needed to include a link.
Cheers, Wim
On Tue, 22 Mar 2022 at 11:05, Ed Merks <ed.merks@xxxxxxxxx> wrote:
_______________________________________________Wim,
Comments below.
On 22.03.2022 10:46, Wim Jongman wrote:
In BIRT, Windowbuilder, and Nebula we successfully use the following workflow:
- Fork the main repo
- Create an issue in the main repo e.g. "My Issue" #1 (#1 being the next ID)
- Make changes in a branch in your fork (not in master/main)!!!
- Commit with "My Issue #1"(include #1)
A few "concerns" here. This approach does look good in the github views, but the issue URI is implicit. That works well (on the github site) when the issue is open in the same repo as the commit, but I expect in the long term, there may well be commits for a single issue across multiple repos. Also, EGit knows nothing about such implicit links so will not show such links in the UI.
It's also possible to include the full issue link like this such that even in EGit, you can see an issue link that you can follow to the github site:
This looks like this in the github pages:
Note how the long issue link is displayed as #2 here. Also note that the #3 is a link to the PR while #2 is a link to the issue. So here the implicit URI is different depending on the location of the #<fragment>. I'm not sure how EGit might create/display such links in the future...
So perhaps it's worth considering including the full link to the issue in the body of the commit message?
Just a thought...
- Go to GitHub in the main repo. GH offers to create a PR
- Use "My Issue #1" as the topic. The PR will be called "My Issue #1" #2
- Start Review
- Keep committing on your fork branch
- PR is accepted
- Go to your fork and "Fetch upstream" [1]
Yes, this is a PITA. :-( It's hard to keep something like the following up-to-date if you also have to go off into github and manually fetch each fork (if you have one) before Select All and to a Pull.
I wondered if there were some way to make this easier with multiple configured remotes, but I don't understand that approach well enough
[1] Fetching upstream is currently a pain. I have started a discussion here. Please also comment or upvote:
Cheers,
Wim
_______________________________________________ platform-dev mailing list platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________ platform-dev mailing list platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
