Python ports 3

[villares]

Binary Digits, Factorial and Bitmap

Jeremy, please advise if I'm doing it wrong or right... I still feel insecure with the workflow. Thanks for being a such a gentle mantainer!

[jeremydouglass]

This is great.

The only thing that I would suggest before opening a PR is to rebase your feature branch onto master / the latest release, then PR. That isn't a big deal in the case of atomic changes like these, but it is good to do.

You can do it like this to update this PR.

1. open GitHub Desktop (this is what you use?)
2. check out branch Python_ports-3
3. Branch > Rebase current branch
4. Select "master" and start rebase

You then need to "git push --force-with-lease" your Python_ports-3 branch. That should update this PR automatically.

[villares]

Check out means "make it the current branch" yep? It complains I can't do it because there are no commits... And by the way... what does "rebase" mean?

[villares]

Should I do the rebase with your upstream/master?

[jeremydouglass]

Should I do the rebase with your upstream/master?

Check out master and pull. Now your master is up-to-date with release v0.13.

Check out Python-ports_3.

Then rebase onto your master (the one on top).

"Rebase" means that you are creating three new commits -- BinaryDigits, Bitmap, and Factorial -- on top of a new "base". Your old commits were proposed as changes on top of something from a while ago. You rewrite them as proposed changes on top of what we have now.

The gray is your current pull request. Once you rebase, the orange will be your new pull request. Because your changes are all new files, there won't be any tricky merging required and the rebase will happen automatically -- but if there was, you would catch it before you proposed changes.

[villares]

Check out master and pull. Now your master is up-to-date with release v0.13.

You mean make a PR updating my master with your v0.13 right? (because Pull Ctrl+Shift+P does nothing)

[villares]

:crossed_fingers:

[jeremydouglass]

You mean make a PR updating my master with your v0.13 right?

No, I just meant bring your master up-to-date from origin. That should be a fast-forward -- you don't commit to your master at all. These "get newer stuff" "update from upstream" commits aren't necessary. (image from SourceTree)

Here is what it the graph should look like. Your master is the same as origin/master. (v0.13). Then you rebase your branch onto that -- your master, which is the same as origin master. Then you have three commits coming out of master with a new name. Then you PR.

You can see that I have two little feature branches there as well. If we make a couple more releases before I finish them, I'll do the same thing -- check out StartFromMain, then cherry pick or rebase it onto whatever the latest master is, like chopping off a tree branch and grafting it back on the tree, only higher up. No extra commits, pulls, or merges.

I'm happy to move commits around myself if this is stressful or frustrating in any way -- I want contributing to be fun, and for you to focus on the part of it that you care about. I can see that GitHub Desktop is not a great tool for learning how this stuff works, and I'm still learning myself. But if you want to figure it out, I'm also happy to help.

[villares]

As you can see... I have no idea of what I'm doing. It is very stressful at times, but you are very kind and so I'm learning a lot. Now I have an idea of what a rebase is...

I have a hard time with the pull instruction you gave me. I'm struggling on how to fast-foward (?) my fork for a long time now.

Let's try once more on my next PR, shall we? Please send me again instructions on the step before the rebase...

[villares]

Check out master and pull. Now your master is up-to-date with release v0.13.

I can do it at the terminal if you give me detailed instructions. Sorry if this is a waste of time...

Maybe something like this: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/syncing-a-fork

[jeremydouglass]

Sorry for the delay on this. If you look the last list of commits above, you'll see the first commit -- "merge remote" -- that one is the only problem one for me. I'm going to cherry-pick this out, and the very next one we'll walk through it exactly right.

[jeremydouglass]

Merged with 7e8d2dd599eb8b83123331e08892eb513cbe8d29

[villares]

Cool!

• I have this Rotating Cube example on a branch, do you think we could try to un-mess it? https://github.com/villares/rosetta_examples_p5/tree/draw-rotating-cube

If you think it's not worth the trouble for this one, I can always backup the example, delete the fork and start over :)

Cheers!

[jeremydouglass]

Okay, first let's clean up your master. You keep merging things into it, and this means that your features aren't clean.

Make sure that you don't have any uncommitted files first -- the hard reset could destroy them.

Please set your master back to the last release:

git checkout master
git reset --hard v0.13

Create-and-switch-to a clean branch for your feature:

git branch draw-rotating-cube

You currently have one commit on a dirty branch, so let's cherry-pick it onto this clean branch:

git cherry-pick bc635cc

Now any time you want, you can add more commits to your draw-rotating-cube branch. When you are ready, just open a PR from there. If there are a bunch of little messy commits I can easily squash them into one commit -- "examples -- DrawRotatingCube -- add"

But what if you want to add another feature, like a set of audio sketches, and it also might turn messy? Don't branch off of DrawRotatingCube. Instead, let's just make a new branch off whatever the last release is:

git checkout v0.13
git branch audio-sketches

Now do what you want, then open a separate PR from audio-sketches. If it is messy, I can squash when I accept the PR.

But what if you checked out a feature branch on an old release a long time ago, and there have been several releases since then?

Let's test it. We'll branch a feature off a very old release and make a commit, as if it happened months ago.

git checkout v0.10
git branch fake-old-feature
touch foo.txt
git add foo.txt
git commit -m "foo.txt"

We want to open a PR now, but this features branches off from a long time ago -- plus, a second problem is that our fork master might be out of date with origin/master.

First, let's bring master up to date if it is out of date.

git checkout master
git pull origin

EDIT actually, on your fork, this is slightly different -- you aren't checking your github repo, but mine.

INSTEAD, if you haven't already defined upstream on your local checkout, do so:

git remote add upstream git://github.com/jeremydouglass/rosetta_examples_p5.git

Then update master from upstream, not from your fork's origin.

git checkout master
git fetch upstream
git merge upstream/master
git push

Remember, we don't commit to local master! That's what makes it fast and easy to "fast-forward" to whatever remote master is doing without strange merge commits. As long as we haven't committed to master, this pull will just move the "master" branch label forward.

Now let's rebase our feature -- cutting the base of the branch off, and sticking it back on a new base higher up on the tree. We could rebase onto the last release, e.g. v0.13, or we could just rebase onto the very latest from origin/master (which we just pulled a minute ago).

git checkout fake-old-feature
git rebase master

That moved our commits. Now we can open a PR.

[jeremydouglass]

(Just realized I should edit the above to show you how to update master with your fork, not an original repo like I'm using. Edited.)

[villares]

Hmmm, I think the thing I was missing was git reset --hard v0.13 as a way of updating my master I think I was doing the new branch for each feature right, but my branches were always being rebased to a messed master anyway so... let's see.

[villares]

Hmm I think I had upstream set, at least it doesn't let me use git remote add upstream git://github.com/jeremydouglass/rosetta_examples_p5.git I'll try the

git checkout master
git fetch upstream
git merge upstream/master
git push

but I think this is exactly what I was doing before... anyway I'll keep a copy of your instructions and study them again next time.