On the other hand, working together is also difficult in the GitHub workflow if we work with forks. I realized this when I was working with bug 572080
Starring: Repo X-Eclipse, fork X-Jill, and fork X-Jack Story: Jill works on her fork and finds an unrelated issue. She reports this and Jack decides to work on it. Jack creates a branch in his fork and creates a PR. Workflow: How is Jill going to review/test this? I can't think of an easy workflow. Jill has to add her, Eclipse, and Jacks repo as a remote and has to start juggling branches from three remotes. (Imagine adding more contributors.) Possible solution: J&J don't create forks but create branches in the clone from main and are allowed to push to a branch in the main repo. On Mon, Mar 22, 2021 at 1:39 PM Wim Jongman <wim.jong...@gmail.com> wrote: > I want to mention one thing in Gerrit that I probably do wrong or is > indeed difficult: Working together on the same change. > > When I work on my own, I can sequentially push new changes. > > If someone is helping me (e.g. changed the commit message in the Gerrit > UI, or anything more substantial) then my workflow is broken. If I > unknowingly commit my change but it is out of sequence when I push. When > you are not a git grandmaster *and* understand how Gerrit organizes the > different change-sets then this can become very difficult. Often leading to > abandoned changes and pushing again. > > This does not stimulate working together. > > This process is much easier to manage when working together on the same > branch. > > Cheers, Wim > > (Another difficult thing in Gerrit is the notion of sequential > change-sets. E.g. the author bases one change-set on another. I recently > broke such a scenario when I was trying to "help" by rebasing a change that > broke the relation to another change-set.) > > > > > >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
