When I’m on-line on GitHub, and working on master, or maintenance/gramps51, GitHub informs me when that branch is out of date with the same branch in the main repo.
This does not work with the new beta however, apparently because I created the fork before the new maintenance/gramps52 branch was made. And this applies to the aio branch too.
So here’s the question: How can I get those new branches into my fork?
Use:
git push <repository> <src>:<dst>
where <repository> is the name of your fork, <src> is the source branch and <dst> is the destination branch.
Often <dst> is not specified if the two branches have the same name.
Great question! Till now I hadn’t noticed what @ennoborg did: branches on origin (gramps-project/gramps) created after forking aren’t created in the fork. Or put another way, I didn’t notice that forking automatically created existing branches in the forked repo? Will have to read more about that.
If I understand Nick’s response he’s saying that you have to track the new maintenance/gramps52 branch via your fork on GitHub. I did that via command line and it worked fine, and if you want to do it via GitHub web, go to your fork > Branches, and then “New Branch” and set the parameters like this and then you will have a 5.2 branch which tracks a branch of the same name on origin:
Learned something new today 
Interesting …
In a PM, Nick gave a link to some help on the GitHub site, and part of that worked before I read what you did online.
And part means that things here are a bit messy, but I think that I am tracking the right branch now. And when I can find time, I may dig up some material from a git course that I once had, paid by our government. 
Nick gave me the following instructions when I mentioned not being able to keep my Fedora box in sync with with the 5.2 revisions.
I was hoping to work it into a less frightening wiki document than our current set. One that makes it easier for non-developer users to move up to beta (or alpha) tester. Or for experienced developers to explore with less onboarding investment. And where the simple instructions work on all 3 primary platforms. Unfortunately, my understanding is too shallow to write a proper page.
In the terminal, clone the repository with:
git clone https://github.com/gramps-project/gramps.git GrampsChange directory:
cd GrampsCreate a tracking branch:
git checkout -b gramps52 origin/maintenance/gramps52When you want to pull in the latest changes use:
git pull
and earlier eMail advised the following after refreshing
Change directory to the local instance of the Gramps beta:
git clean -dfx
python3 setup.py build
python3 Gramps.py
I see what you mean, but I gave up on that page a while ago, and used the info on GitHub instead, meaning the README and INSTALL files. They’re more up-to-date, and a bit easier to maintain. I see that they’re already mentioned on the wiki, and think that they should be treated as the primary resource, because you get them automatically when you use GitHub or clone the repository.
This does not mean that the wiki page can be deleted, far from it, but I’m not in favor of updating it either. Users should of course know how to install git before they can clone the whole thing, and we already have a page for that, which might be outdated a bit too.
Right now, most of the best info is here, not on the wiki, and that situation will most likely continue to exist, because this is the place where we talk.
It also helps if you can discover how things work on Fedora by experimenting a bit. And by doing that, you can figure out what parts of the wiki are still needed.
This is the minimalist approach that has always worked for me. I only read manuals when I get stuck.
This thread is specifically about adding new branches in origin to a fork and should be marked solved because @ennoborg question is answered in two ways: by command line in Nick’s response #2 and via GitHub UI by my response #3.
@emyoulation What you’re tracking is a more general and probably deserves its own thread? I’m happy to help answer any git/GitHub I can.
Can you choose which you feel is the best solution? (Or the @codefarmer post which indicates 2 equally valid solutions.)
Which of which? There are two subjects in this thread, so I have no idea what you’re referring to here.
What are the 2 subjects? Maybe you could re-state those subjects with a link to the solution for each … thoen mark the subject re-statement posting as the ‘solution’?
We have a thread about branches, and I got a solution for that, in a PM from Nick. And you were in that private thread too.
But the real answer is, that there is no such thing as a best solution, because that depends on the context.
And for the same reason, there is no best solution for the install issue either.
Thanks. I’d like to take you up on that offer. But im seriously behind in delivering for 5.2 docs.
But 1 thing that’s needed (soonish) is documentation on how to use the make.py on GitHub to generate .tgz files and individual addon lists. (I can use that script locally on Fedora but not Windows.)
If everyone experimenting with a single addon could generate a 5.2 “Project”… ready for the Addon Manager… then it would open up beta testing opportunities.
Let’s take this offline.
Documentation for Mac would also be helpful.
