[Pharo-dev] contribution workflow

Ben Coman btc at openinworld.com
Fri Feb 1 12:06:21 EST 2019

On Tue, 22 Jan 2019 at 17:28, Guillermo Polito <guillermopolito at gmail.com>

> Hi Ben,
> I'll just expand a bit on what Pavel said.
> On Mon, Jan 21, 2019 at 4:59 PM Ben Coman <btc at openinworld.com> wrote:
>> I'm not sure how closely my contribution workflow matches the standard
>> advertised, so just wanted to share it for feedback.  I may remember
>> wrongly, but my understanding of the advertised process was forking the
>> "pharo-project/pharo" repo, then cloning from my fork.  However I found it
>> awkward to keep the "master" branch of my fork synchronised with upstream.
> It's important to understand that you don't need to keep any branch in
> your fork synchronized ^^.
> Pull requests bind two branches, not two repositories.
> Your repository may have 30 branches, all outdated, and the only one that
> needs to be "up to date" is the one participating in a pull request.
> Even, I'd say it's not really required to have the branch of the PR up to
> date either, as git will just make a merge with it, calculating correctly
> the point of divergence between the two branches. However, making a branch
> that started too far away in the history (too old) will just increase the
> possibility of a merge conflict.

> Actually, the easiest is that you start working on a branch whose tip
> points to the same commit the image was created from.
> This is to make sure that:
>  - you will have correct diffs
>  - your PR does not introduce commits that you did not intend to

Sure, I often do the same to avoid feeling lost when I don't understanding
where extra changes are coming from.
However right now I have a PR from November that didn't make it into Pharo
7 and I'm now trying bring forward for Pharo 8.
Could work with me to reproduce this to see where I'm going wrong...

My image is up to date with Pharo 8, 2019-01-31 19:23, commit 2c0b5d0.
I repaired the "pharo" repo  such that remotes after repairing are...
* origin = git at github.com:bencoman/pharo.git
* pharo-project = git at github.com:pharo-project/pharo.git
though if you use https the rest of this workflow should go the same for

Double-checked I was up to date by again checking out
Now I want to bring forward my changes from
Right-clicking on it I only the choice to "Checkout branch", but I don't
want to do that
since I feel its likely to break something.  A checkout doesn't focus on
the package my
changes are in but reverts months of changes through the whole live

The <Merge> button is another option, choosing "origin" then
In the preview window is a massive amount of changes that have nothing to
do with me.
I guess its again months of every else's changes to Pharo that would be
risky and confusing to proceed.

I feel what I need is something like "origin/22637-Minor-cleanup-of-Delay"
right-click > Rebase to HEAD
which would determine the common ancestor f2078b5 and integrate just my
changes since then.

I can't see any other options.   How would you handle it?

cheers -ben

P.S. Side info on conflict if you bump into it.  DelaySpinScheduler was
removed from Pharo 7 after I submitted that PR for issue 22637.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190202/726f4502/attachment.html>

More information about the Pharo-dev mailing list