Update Addon to 2.80 API

[Oxervision]

Hi, I have followed the instructions of luketimothyjones to fork the codebase, in the Blender 2.80 compatibility topic, you can see at what point I am.

[samipfjo]

Worth noting, I messed up and forgot to tell @oxervision to change fork targets from master to the 2.8 branch on the PR, so that's on me.

[Oxervision]

Is it possible change that now?

[samipfjo]

Yeah, you'll just need to create a new pull request that targets the 2.8 branch and delete this one.

As a general rule, I've found that when working with Git it is frequently easier to finish doing things the wrong way and then do it the right way afterwards than it is to try and change things partway through.

Git has a somewhat steep learning curve and there are some complicated things one has to do to fix mistakes partway through, so don't feel bad about not understanding it. Many experienced developers still sometimes struggle with getting Git to cooperate, even after years of experience with it.

I find it helpful to curse Linus Torvalds when I run into issues, because it is frequently easier to blame him for designing a complicated system when I am frustrated than it is to admit that my mistake it 100% my fault haha.

On Fri, Jul 5, 2019, 10:31 AM Oxer notifications@github.com wrote:

Is it possible change that now?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/friggog/tree-gen/pull/32?email_source=notifications&email_token=ABQGADZMNMOTKMZEI3Y6U73P56AQJA5CNFSM4H6MZUCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKAIVY#issuecomment-508822615, or mute the thread https://github.com/notifications/unsubscribe-auth/ABQGAD6KDZBSWKSXKRQFUNLP56AQJANCNFSM4H6MZUCA .

[Oxervision]

you'll just need to create a new pull request that targets the 2.8 branch and delete this one

Well, for me it is not clear, can you tell me step by step the process. What is the 2.8 branch and where is? Where do I have to make the pull request? How can I delete this one?

Sorry, I'm lost in this but, I learn quickly

[samipfjo]

No worries, let me walk you through it. It is going to be a little more work than I originally said, but the following pictures should make it easy. Note that my version of the app looks somewhat different because I use Windows. I assume that the File | Edit | (…) | Help menu items are in the menu bar at the top of your screen, so pretend that they are the same for simplicity purposes :P

Make sure you are on your fork of tree-gen

Switch to the blender-2-8-compat branch

Merge upstream/master into blender-2-8-compat. Currently the code changes you have made are in your fork’s master branch.

Create a new pull request

Make everything above the red line is the same (it should be by default)

Then fill out the PR and submit it as you did before.

[samipfjo]

Now that we have got you through that, let’s go through some Git terminology to get you more comfortable doing things on your own in the future.

repository (sometimes shortened to repo): The collection of a project’s code, including all branches belonging to that repository

fork: A personal copy of someone else’s repository

upstream: The repository that you forked from

branch: Somewhat like a fork of your own repository. You use them to separate different collections of changes that you make to the code. For example, you may be working on implementing feature A and feature B at the same time, but they are entirely separate features, and do not depend on each other to work. To keep things clean, you would have a separate branch for feature A and feature B with names matching the feature being added.

master: A special branch that contains the current state of a repository. This is the thing that all of your branches copy their code from when you create a new branch, and is what is displayed on a project’s GitHub page.

origin: The online version of a repository, also known as the remote repository. Online versions of branches are called remote branches or remotes, and are referred like this: origin/my-branch

merge: Update the current branch from another branch, hopefully automatically.

merge conflict: What happens when the “hopefully” above fails. The branch you are trying to merge into your branch has made changes to the code in the same place that you have since the last time you merged its changes into your branch. These must be fixed manually because Git doesn’t know which one is more important and/or if combining the two will break your code.

commit: Add your current changes to the branch you are working on. Think of this like creating a branch of your branch and then merging it all in one step. When you get done adding part of the feature you are working on (a feature of the feature, if that makes sense), do a commit so that the change you have made is separate from the rest of your changes. Forcing yourself to be diligent about committing frequently will save you a lot of time, as it creates a record of each change that you’ve made with nice labels that you can refer back to if something breaks.

push: Upload all of the commits you have created since your last push to origin. Without doing this, all of your commits will stay on your local machine and will not show up on GitHub. That is, unless the GitHub app automatically pushes your commit, which it frequently does.

fetch: This is a little tricky to explain. Basically, Git has a local copy of all of the remotes in a separate location from your branches (somewhat like a special branch), and fetch updates your local copy of the remote for the branch you are currently working on. This does not merge the remote into your branch, it just keeps your local copy of the remote up-to-date.

pull: Perform a fetch, then attempt to merge any changes from your local copy of the remote into your local branch. This only affects the branch you are working on currently.

pull request: A request that the changes made in your branch be merged into another branch, usually upstream/master or (less frequently) origin/master. The repository’s owner will review the changes, make suggestions for changes, and/or make changes on their own and, once they are happy with it, merge it into upstream/master.

Hopefully that will be enough to help you get started with Git. Like I said before, the learning curve is a bit steep. Don’t be intimidated; you can totally handle it, and you do not have to learn everything at once. As with most things, once you understand the terminology you can tackle pretty much any issue you run into by Googling it.

[Oxervision]

The first, thanks for your patience, help and time!! I did your steps one by one, and I hope all is correct. Your little manual about Git is very interisting and clarify me the general terminology used, the fisrt step in this world of collaborative programming. I'm drawing teacher in high-school, apart of Illustrator, graphics designer, painter...but I'm too a student in continuous learning. Again, thanks!!

[samipfjo]

Of course! I was once where you are now, and it was by the grace and generosity of others that I am where I am today (and will grow to where I will be tomorrow). I see it as my responsibility to do the same for others in return. I would imagine a teacher would be familiar with that feeling as well.

The guide took me a little while to put together, so I am very glad you found it useful. It was a great exercise in refreshing my Git knowledge as well!

I am also a "student in continuous learning"; "jack-of-all-trades, master of some" as the saying goes. The number of things I find interesting in this world is far beyond that which I could learn in many lifetimes, let alone one, but I see that as a challenge rather than a curse :)