On Tue, Mar 22, 2022 at 1:25 PM Lars Vogel <lars.vo...@vogella.com> wrote:
> Sorry, if that was said before (I did not read all discussions in > detail) but committers can create PR for the same repository without > the additional fork. > > So a possible workflow is: > 1.) Clone repo > 2.) Create new local branch > 3.) Push local branch to new branch in origin > 4.) Create PR from new branch to master / main in the same repo > > This removes the need to sync your server fork. > Lars, this workflow is good for small and/or private projects. But for bigger communities it's better to stick to official github recommendations ( https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models) Shared repository model - "This model is more prevalent with small teams and organizations collaborating on private projects." and I would not call Eclipse being small team nor private project.) Benefits from using a fork and branch in your fork has at least these multiple benefits: * your changes are independent and not create churn in the main project * committers and contributors follow same procedures so better understand each other * put less burden on CI - every branch in main repo is scanned and checked for compilability and test status > > Best regards, Lars > > On Tue, Mar 22, 2022 at 11:22 AM Rolf Theunissen > <rolf.theunis...@gmail.com> wrote: > > > > Hi, > > > > What comes to mind is 'origin' and 'upstream' repositories. Where > 'origin' is your fork and the 'upstream' the forked repo. > > Your workflow seems to fetch from 'upstream' (aka eclipse) and push to > origin (aka me), after which a PR is made from 'orgin' back to 'upstream'. > > With the right settings this might be able to set the default fetch and > default push locations in EGit too. > > > > > https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-for-a-fork > > > https://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-on-github > > > > > > Op di 22 mrt. 2022 om 11:13 schreef Mickael Istria <mist...@redhat.com>: > >> > >> Hi, > >> > >> On Tue, Mar 22, 2022 at 10:46 AM Wim Jongman <wim.jong...@gmail.com> > wrote: > >>> > >>> Go to your fork and "Fetch upstream" [1] > >> > >> Why do you need to do that? Particularly if you never use master/main? > >> FWIW, may workflow is > >> $ git fetch eclipse master > >> $ git checkout FETCH_HEAD > >> [... do changes ...] > >> $ git commit -m "My super fix (#123)" > >> $ git push me HEAD:refs/heads/issue-123 > >> Create PR > >> If needed, improve, rebase, `git push me --force HEAD:issue-123` > >> Upon PR merge, just remove my issue-123 branch. > >> > >> This allows to not care about the master/main branch in my fork. I can > even happily delete it, and it gives me more guarantee to keep in sync! > >> _______________________________________________ > >> platform-dev mailing list > >> platform-dev@eclipse.org > >> To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev > > > > _______________________________________________ > > platform-dev mailing list > > platform-dev@eclipse.org > > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev > > > > -- > Eclipse Platform project co-lead > CEO vogella GmbH > > Haindaalwisch 17a, 22395 Hamburg > Amtsgericht Hamburg: HRB 127058 > Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel > USt-IdNr.: DE284122352 > Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: > http://www.vogella.com > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev > -- Aleksandar Kurtakov Red Hat Eclipse Team
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
