Understanding how to best structure branches to contribute to a 3rd party project
Locked
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 <[hidden email]> 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. |
Re: Understanding how to best structure branches to contribute to a 3rd party project
|
|
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 <[hidden email]> wrote:
|
|
|
In reply to this post by Tim Mackinnon
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 <[hidden email]> 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 |
Re: Understanding how to best structure branches to contribute to a 3rd party project
|
|
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 <[hidden email]> 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 <[hidden email]> 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 |
Recommended way to move a package
|
|
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
David
Totally Objects Doing Smalltalk since 1989 |
Re: Recommended way to move a package
|
Administrator
|
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
Cheers,
Sean |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |