Tim, This is a common open-source situation and what you described seems to me to be the best practice: (1) changes should be proposed as small, self-contained branches; (2) you should keep your main/master branch up-to-date with the upstream repository so that you can create new branches for new pull/merge requests; and (3) you should create your own branch with the combination of things you want to include. I don’t know of a way around this.
James > On Apr 1, 2021, at 3:15 AM, Tim Mackinnon <tim@testit.works> wrote: > > Hi Everyone - I tried asking this on Discord, but I think it got a bit lost - > and perhaps for more philosophical questions, here is better. > > So - I’m wondering what is the recommended way to work with another project > you want to contribute to (in my case CodeParasides). So I know I can fork it > and put the fork in my baseline. But I’m assuming contributions are best > done discretely on a branch per proposal (this seems to be the Pharo way - > and it makes sense for ease of understanding), but if you have a few of these > contributions in play (while the maintainer is evaluating them) would you > then have your own “combination” branch to consolidate all those fixes until > they get merged in? > > I’ve started to try this, but merging between branches gets a bit tricky - a > few times now it seems that Iceberg shows me misleading info on what is being > added/removed (it always looks like my changes are going to be removed, when > if fact they get added - so its a bit of a leap of faith on this). > > So I’m wondering if I’m overcomplicating things - or whether this is the > suggested way to work with another project? > > Tim
