Understanding how to best structure branches to contribute to a 3rd party project
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
Hi Tim. I prefer to have individual branches for each feature or bug
because it eases the review process for the original project. You can merge
all this branches in your fork if you need it together before they are
merged upstream.
Unless one feature depend on other one.
I usually do the merge using PRs on GitHub via the web interface or using
the git command line client and didn't find too much problems so far.
On Thu, Apr 1, 2021, 07:15 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
Hi Gabriel - appreciate your input. I too think that branches for separate features /contributions makes sense.
However when you say “merge all branches on your fork” - is that merge them on main (master) ? But I think that would make it difficult to create your next branch for a clean feature (or am I misunderstanding?) OR perhaps you are confirming my thought that you need a combination branch in your fork that you keep merging too?
Interesting that you merge on GitHub - I have submitted PRs that way (the iceberg option never seems to work for me against non Pharo remotes), but not tried merging non trivial st code in GitHub - maybe I should.
Tim
On 1 Apr 2021, at 21:39, Gabriel Cotelli g.cotelli@gmail.com wrote:
Hi Tim. I prefer to have individual branches for each feature or bug because it eases the review process for the original project. You can merge all this branches in your fork if you need it together before they are merged upstream.
Unless one feature depend on other one.
I usually do the merge using PRs on GitHub via the web interface or using the git command line client and didn't find too much problems so far.
On Thu, Apr 1, 2021, 07:15 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
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
Thanks for chipping in James - its reassuring that I’m not overcomplicating things - however now I need to practice doing this for real - I’ve been doing individual branches for contributions reasonably fine (Iceberg does seem to trip me up from time to time - but can’t quite put my finger on it) - but the next step is to practice that “combination” branch and also how to keep it up to date… that’s the real art in all of this… and will Iceberg help or hinder me in this activity (not to blame Iceberg - its quite a tricky concept in fairness - its just interpreting what its showing that is often the trick).
Tim
On 2 Apr 2021, at 00:52, James Foster Smalltalk@JGFoster.net wrote:
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
I have Pharo 8.0 on my MacBookAir and Pharo 9.0 on my server. I have having lost of trouble doing what I thought would be a simple process - File out a package on one and file it in on the other but I having lo=ts of trouble - to many issues to document to be honest.
So, tell me, how do I do this so that my package is in the new image along with the code extensions to other classes listed as being in the package.
I can get the basic package in but the extensions never appear and I have too many to import individually.
Help!
David
Long Haired David wrote
File out a package on one and file it in on the other
This is the lowest level approach. Except for the simplest cases, you're
probably better off using Metacello.
Long Haired David wrote
I can get the basic package in but the extensions never appear
Are the classes to be extended loaded in the image beforehand?
There was an old bug I reported [1] where extension methods were not
included in a package fileout, but I don't recall it ever being fixed. If
you look at the fileout file in a text editor, are the methods there?
Again, I would just use Metacello...
Cheers,
Sean
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html