I’m currently working on adding routines to v1.07 of GC. As others go through and maybe make adjustments to 1.07 or maybe it goes to 1.08 or 1.09 by the time I’m done, when I submit a PR for for my changes, I’m going to run into conflicts with my code. What I think I would need to do is to somehow merge other people’s changes into my version so that I can produce a PR without conflicts. But what if, for example, groundcontrol.kv was modified by others and I’ve modified the same file. Am I correct and thinking what I need to do is “rebase” my fork? I’m not sure of the terminology and it seems there’s some sort of interactive rebase that may allow me to accomplish this. I just need to know if “rebase” is what I should do or am I totally “off base”?
I’m a github nood too. You do from my understanding need to Fork and your changes get re incorporated. At least this is what I’v seen on other projects.
Thank you
I have forked, but if I generate a PR when done, I’m sure I will get conflicts. I think solving that is called ‘rebasing’… I guess that’s what I’m for is confirmation that I’m on the right track.
You can rebase, that would fix the issues, or at least give you the chance to “resolve conflicts” by highlighting where the conflicts are.
When you create a pull request there will be a “resolve conflicts” button which will give you the chance to do just that also if rebasing turns out to be too difficult.
Feel free to make test pull requests if you ever want to explore how things work, just put a note in them saying what you want on my end.
Honestly - I tread lightly in Github in fear I’ll gork something. This information helps.
Thank you
Ok, thanks… I might just wait until 1.07 is released since there seems to be some work going on to solve some issues.
First, don’t fear git or github. Other than people with direct pull request approval access, there is nothing you can do to the Maslow repository that isn’t fixable. There is also very little you can do to your own repository that isn’t fixable in some way.
Second @madgrizzle, you can do the rebase if you like, but I find that to be a little harder. What I generally do, is just merge in upstream/master. (I named the maslow repo upstream).
You can see it in this commit:
https://github.com/MaslowCNC/Firmware/pull/384/commits/5887321c352a86f1f419a304cc78d02700f96f1c
What happened was as I was developing improvements to the settings process, we added the chain sag setting. So I had to merge that in and fix the conflicts. I like this process because it leaves a good record in the form of the commit that shows your “work” resolving the conflicts making it easier to track down mistakes.
Happy to help if you want me to look at a specific branch.
Well, I won’t stress of it for the time being. I’ll work with you when the time gets closer.
I wouldn’t be too afraid of it. A few major reasons for revision control software is to ensure nobody screws everything up, and all incremental work gets captured. If something goes wrong, you should be able to revert the changes. Git should have utilities which act as a merge, so that your modifications are woven alongside others’; there should be some intelligence built into the software. There should be utilities which enable you to work through conflicts. Generally, you won’t get any conflicts unless the same content (on a line-by-line basis), in the same file, is modified by two different people. Commit early and often.
Part of the issue is that what I am working on requires installation of new packages. OpenCV, scipy, imutils, and numpy in particular. So I’d like to make sure this whole thing works before doing a commit.
To make Windows binary releases, what tool is used to compile everything? py2exe?
Look at ‘build.bat’ in the ‘build’ branch of GC.
Thanks… pyinstaller…
While this reply is to @madgrizzle it is an open question. Can there be a checkbox to enable this that would wait until the option is enabled to add those files that are required?
Thank you