OK lets regroup, my last commit is not what was intended!!!
I did a merge and beleived I made the correct changes, then committed and did a pull, at which time I was told I was up to date. So I assumed because my changes were correct at my end, then that is what was committed.
I have just realised this is not the case, and the only change was the version number!!!??? This was dicovered whilst setting up an AstroBerry, and pulling the latest nightly, I noticed my changes were not there.
So I have two file on my development end, that need to be committed via a pull request?
I guess the steps are
1. Create a commit (should I do some sort of sync first, and if so what should I do?).
2. Create a Pull Request at the head end, and associate the above commit?
I won't do anything until I get some feedback, as this is how I started getting in this mess, and can't understand why only the version number was committed?
I've double checked the code and it looks like everything is as intended. Tested too!
As stated many times before, I have never worked in git as a developer, and I am by no means a linux guru, so your previous comment really doesn't help me get any closer to a solution. My biggest concern is that I will loose my changes, by not really understanding what is going on, I also understand you are a very busy man, and don't have time to answer these sort of requests. Unfortunately I too am busy, and can't commit the time to learning git at this moment in time. Maybe we need a developer git help forum? I guess my problem was I didn't do a "git fetch" before starting my edits at lunch time?
After a bit of googling, I think I am back to some sort of synchronisation. You said "if I can create a PR....", I believe I already had, with a commit from myself, then one from you and now another from me just now. I manually opened the problem file with "nano" (horrible text editor) and then checked line by line looking for merge messages (there must be a better way of doing this?)
Anyway, I have done a commit. and my end says it is up to date, so I assume somehow I have muddled through and pushed my changes?
So I have hit this problem, I have no idea what todo?!
alan@alan-kubuntu:~/indi$ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 8 and 11 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
alan@alan-kubuntu:~/indi$ git commit -m "Update myFocuserPro2 to work with firmware 291 or greater"
[master 3874b71] Update myFocuserPro2 to work with firmware 291 or greater
2 files changed, 22 insertions(+), 31 deletions(-)
alan@alan-kubuntu:~/indi$ git pull
CONFLICT (content): Merge conflict in drivers/focuser/myfocuserpro2.cpp
Automatic merge failed; fix conflicts and then commit the result.
How do I resolve this?
I have updated my focuser firmware to the latest 291, and set the Indi focuser driver to only work with 291 or greater.
I have made sure isMoving and Max position behave as expected.
I have implemented Reverse Motion, and removed option tab Reverse Direction (to use standard functions).
I am about to push these changes (this will also revert KNRO earlier change).
Roberto, I agree in principle that the sent command should be in the format #xx: where xx = leading zero 2 numeric (00-99), but rather than go back to change any that are not, just use this going forward.
I see you have modified the MaxPosition request back to #08:, unfortunately KNRO has submitted a change to #8:, without checking version of firmware (it would now be broke for 280, which wasted a bit of my time trying to understand why I was no longer reading the MaxPosition!)
Leave your change as is (#08:) in 291, and I will upgrade my focuser to 291, and retest, and fix any issue I see. I will then make the base firmware check equal to or greater than 291.
So to be clear:
KNRO to revert the :8# change back to :08# ;
Roberto, leave 291 as is (possibly point me at inputs or outputs they may have changed since 280?) ;
I will update to 291, test and fix ;
Does this seem acceptable?
Very nice post, and totally agree with all the sentiments raised. I too am here developing, mainly because my focuser wasn't supported, so wrote the driver for it. That's what I like about open source, if it doesn't do what you want, then implement it!