Mickael, yes your WF is very cunning, I will try that. I think the two methods can happily co-exist.
My proposed WF is arguably a bit easier for people that aren't that Git savvy. In my experience, it works very well to get people started. Also, we need to discuss the --force parameter. It will not work well with the Github review system. I propose to just keep committing on the branch (a bit like Gerrit change sets) and then always(!) Squash and Merge Cheers, Wim On Tue, 22 Mar 2022 at 11:13, Mickael Istria <mist...@redhat.com> wrote: > Hi, > > On Tue, Mar 22, 2022 at 10:46 AM Wim Jongman <wim.jong...@gmail.com> > wrote: > >> >> 1. 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
