Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-dev] Github workflow 
> Given the plethora of repositories that comprise
> the Eclipse SDK
Even though it was considered "not important" I always has suggested to actually merge related stuff into one repository, this splitting across different repos is just a pain, and we should not blame the tools for not supporting it well enough but think that obviously things belong together.
Anyways, if one like he can reference other repositories or issues as well, github will detect links or shortcode like eclipse/<somerepository>#1234 

Am 22.03.22 um 13:15 schrieb Ed Merks:

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:

     1. Fork the main repo
     2. Create an issue in the main repo e.g. "My Issue" #1 (#1 being
        the next ID)
     3. Make changes in a branch in your fork (not in master/main)!!!
     4. 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...


     1. Go to GitHub in the main repo. GH offers to create a PR
     2. Use "My Issue #1" as the topic. The PR will be called "My
        Issue #1" #2
     3. Start Review
     4. Keep committing on your fork branch
     5. PR is accepted
     6. 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:
    https://github.com/github/feedback/discussions/13221

    Cheers,

    Wim

    _______________________________________________
    platform-dev mailing list
    platform-dev@xxxxxxxxxxx
    To unsubscribe from this list, visithttps://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, visithttps://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

Back to the top