Closed vanepp closed 4 years ago
This is the 5.1 version of the shield, but in the fzp file the version tag is
<version>4</version>
Is that intended?
@vanepp: I updated this PR by merging in the latest changes (go version had to be increased, because some package was not available anymore for go 1.10, and I minfied the icons files). So you might want to sync first if you have additional changes.
"This is the 5.1 version of the shield, but in the fzp file the version tag is
Is that intended?"
Mostly due to inattention, I just left it at what it was set to in the original. It isn't clear what the version field is supposed to be, I suspect since this is the first version of the part it should probably be 1 because I suspect it is supposed to be the version of the Fritzing part. It is used by the obsoleting mechanism, via a special value, according to the parts file format (I haven't yet gotten to figuring out how obsoleting works, it has a number of options in a number of places). I'll try and sync my repos which will be a good test of whether I can in fact keep them properly synced, and change the version numbers to 1 as I suspect most folks do as I did and just use what is there. What the version number should be is yet another thing to research when I get time :-) . If the numbers should be starting at 1, then the check script should be checking for that. The hard part may be figuring out if there is already a version 1 part, but a scan of the parts repository should pick that up in most cases I think. How do you minfied (minify as singular?) the icons? That is something the parts script could do as well. I've been thinking of making the default (overrideable by a command line flag, for when you want a separate icon file as some parts do) to make the icon file the breadboard file as that is one of the options (and the usual one) in parts editor, to save space. We already have the breadboard svg, we don't need a second copy as the icon file and Fritzing is happy to use a breadboard scg as the icon. Reducing the size of the icon would be a performance gain in rendering as well though and thus well worth doing. I'd also like to have an option to specify a pcb svg from core (but that would take a code change to be able to specify that you want a standard footprnt) as we have many redundant copies of DIP(number of pins) pcb svg files when we really only need one.
Edit:
No, I still don't know how to do this.
$ git status On branch develop Your branch is up to date with 'origin/develop'.
nothing to commit, working tree clean
$ git remote -v origin https://github.com/vanepp/fritzing-parts.git (fetch) origin https://github.com/vanepp/fritzing-parts.git (push) upstream https://github.com/fritzing/fritzing-parts.git (fetch) upstream https://github.com/fritzing/fritzing-parts.git (push)
$ git fetch upstream remote: Enumerating objects: 11, done. remote: Counting objects: 100% (11/11), done. remote: Compressing objects: 100% (6/6), done. remote: Total 11 (delta 5), reused 7 (delta 5), pack-reused 0 Unpacking objects: 100% (11/11), done. From https://github.com/fritzing/fritzing-parts
$ git merge upstream/develop Merge made by the 'recursive' strategy. .travis.yml | 2 +- CONTRIBUTING.md | 24 ++- core/{PCF8574.fzp => PCF8574_A2.fzp} | 4 +- obsolete/PCF8574.fzp | 286 +++++++++++++++++++++++++++++++++++ 4 files changed, 311 insertions(+), 5 deletions(-) rename core/{PCF8574.fzp => PCF8574_A2.fzp} (99%) create mode 100644 obsolete/PCF8574.fzp
(this doesn't look right. I would have expected something from my parts which don't appear)
$ git push Username for 'https://github.com': Password for 'https://vanepp@github.com': To https://github.com/vanepp/fritzing-parts.git ! [rejected] develop -> develop (fetch first) error: failed to push some refs to 'https://github.com/vanepp/fritzing-parts.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
then this fails so I'm still doing something wrong. I deleted my fork on github yesterday and re forked it, then made my pull request. So I expected the git fetch upline to get your changes and then be able to push them to my fork on github, but that doesn't seem to be what happened. Can you tell me what I'm doing wrong here? This should be a very common thing to do, but I haven't found any documentation on how to do it (the only one I found assumed a single remote repository, where I have three: the master fritzing-parts, my local copy, and my fork on github). I expected my local copy and my fork on github to be identical since I pushed my local copy to github yesterday and made the pull request, but now it seems to have changed somehow.
edit2:
I think the failure is because I did a pull request on the github repository and did not after doing that do a pull to the local repository (not thinking that the pull request made changes on the vanepp/fritzing-parts repository that aren't reflected on the local repository). So I did a hard reset to get the local repository back before my change above:
git reset --hard b0235d3c8b38e8a1abf4e6674d0a9dfcbf381f10
which I think was one commit too early and wiped out my Arduino sensor changes, then did a pull request expecting that to sync my local repository to vanepp/fritzing-parts.
git pull remote: Enumerating objects: 13, done. remote: Counting objects: 100% (13/13), done. remote: Compressing objects: 100% (12/12), done. remote: Total 13 (delta 1), reused 9 (delta 1), pack-reused 0 Unpacking objects: 100% (13/13), done. From https://github.com/vanepp/fritzing-parts b42181e1..6bbecaf6 develop -> origin/develop Updating b0235d3c..6bbecaf6 Fast-forward .travis.yml | 2 +- CONTRIBUTING.md | 24 +- core/Arduino-Sensor-Shield-v5_1.fzp | 2000 +++++ core/{PCF8574.fzp => PCF8574_A2.fzp} | 4 +- core/gear-motor_2.fzp | 72 + core/ky_006_1.fzp | 92 + core/shaft-encoder_1.fzp | 94 + core/yl99_1.fzp | 92 + obsolete/PCF8574.fzp | 286 + .../Arduino-Sensor-Shield-v5_1_breadboard.svg | 8394 ++++++++++++++++++++ svg/core/breadboard/gear-motor_2_breadboard.svg | 221 + svg/core/breadboard/ky_006_1_breadboard.svg | 651 ++ svg/core/breadboard/shaft-encoder_1_breadboard.svg | 896 +++ svg/core/breadboard/yl99_1_breadboard.svg | 941 +++ svg/core/icon/Arduino-Sensor-Shield-v5_1_icon.svg | 1 + svg/core/icon/gear-motor_2_icon.svg | 1 + svg/core/icon/ky_006_1_icon.svg | 1 + svg/core/icon/shaft-encoder_1_icon.svg | 1 + svg/core/icon/yl99_1_icon.svg | 1 + svg/core/pcb/Arduino-Sensor-Shield-v5_1_pcb.svg | 1176 +++ svg/core/pcb/gear-motor_2_pcb.svg | 88 + svg/core/pcb/ky_006_1_pcb.svg | 117 + svg/core/pcb/shaft-encoder_1_pcb.svg | 183 + svg/core/pcb/yl99_1_pcb.svg | 117 + .../Arduino-Sensor-Shield-v5_1_schematic.svg | 3958 +++++++++ svg/core/schematic/gear-motor_2_schematic.svg | 227 + svg/core/schematic/ky_006_1_schematic.svg | 265 + svg/core/schematic/shaft-encoder_1_schematic.svg | 173 + svg/core/schematic/yl99_1_schematic.svg | 201 + 29 files changed, 20274 insertions(+), 5 deletions(-) create mode 100644 core/Arduino-Sensor-Shield-v5_1.fzp rename core/{PCF8574.fzp => PCF8574_A2.fzp} (99%) create mode 100644 core/gear-motor_2.fzp create mode 100644 core/ky_006_1.fzp create mode 100644 core/shaft-encoder_1.fzp create mode 100644 core/yl99_1.fzp create mode 100644 obsolete/PCF8574.fzp create mode 100644 svg/core/breadboard/Arduino-Sensor-Shield-v5_1_breadboard.svg create mode 100644 svg/core/breadboard/gear-motor_2_breadboard.svg create mode 100644 svg/core/breadboard/ky_006_1_breadboard.svg create mode 100644 svg/core/breadboard/shaft-encoder_1_breadboard.svg create mode 100644 svg/core/breadboard/yl99_1_breadboard.svg create mode 100644 svg/core/icon/Arduino-Sensor-Shield-v5_1_icon.svg create mode 100644 svg/core/icon/gear-motor_2_icon.svg create mode 100644 svg/core/icon/ky_006_1_icon.svg create mode 100644 svg/core/icon/shaft-encoder_1_icon.svg create mode 100644 svg/core/icon/yl99_1_icon.svg create mode 100644 svg/core/pcb/Arduino-Sensor-Shield-v5_1_pcb.svg create mode 100644 svg/core/pcb/gear-motor_2_pcb.svg create mode 100644 svg/core/pcb/ky_006_1_pcb.svg create mode 100644 svg/core/pcb/shaft-encoder_1_pcb.svg create mode 100644 svg/core/pcb/yl99_1_pcb.svg create mode 100644 svg/core/schematic/Arduino-Sensor-Shield-v5_1_schematic.svg create mode 100644 svg/core/schematic/gear-motor_2_schematic.svg create mode 100644 svg/core/schematic/ky_006_1_schematic.svg create mode 100644 svg/core/schematic/shaft-encoder_1_schematic.svg create mode 100644 svg/core/schematic/yl99_1_schematic.svg
$ git status On branch develop Your branch is up to date with 'origin/develop'.
nothing to commit, working tree clean
but now
$ git fetch upstream
owner@owner-PC /cygdrive/d/repos/fritzing-parts
a fetch upstream gets no changes, and the log seems to indicate all the changes including your latest changes have been made, but I'm not sure why.
$ git log commit 6bbecaf6a49c6ceca617ce13c847493edfb3291b (HEAD -> develop, origin/develop, origin/HEAD) Author: Kjell Morgenstern kjell@gmx.de Date: Sun Sep 22 13:21:47 2019 +0200
Minified icons
commit b1c483e32dc1a374226ccf753ddc45bb36f070dc Merge: b42181e1 e79a6976 Author: Kjell Morgenstern kjell@gmx.de Date: Sun Sep 22 13:06:09 2019 +0200
Merge branch 'develop' into 222
commit e79a69765026f3fda8aab1b3e7a4952c28047a62 (upstream/develop) Author: Kjell Morgenstern kjell@gmx.de Date: Sun Sep 22 11:54:41 2019 +0200
Make use of update mechanism, add documentation about the parts update mechanism
commit 03d9b6a1b5f7a293a37b49e2028e9584fceff603 Author: Kjell Morgenstern kjell@gmx.de Date: Sat Sep 14 20:34:55 2019 +0200
Fix PCF8574 update, issue #219
commit 814d5ccd1a4a348a9911bd41aef320c54029b5d7 Author: Kjell Morgenstern kjell@gmx.de Date: Sun Sep 22 11:56:18 2019 +0200
Use a more recent go version
commit b42181e11d44782ac5af8411a1846d3b5ebddd97 (arduino-sensor-shield) Author: Peter Van Epp vanepp@sfu.ca Date: Sat Sep 21 15:17:49 2019 -0700
Arduino sensor shield V5, gear-motor, ky_006, shaft-encoder, yl99 parts
commit b0235d3c8b38e8a1abf4e6674d0a9dfcbf381f10 Author: Peter Van Epp vanepp@sfu.ca Date: Tue Aug 27 19:12:02 2019 -0700
Corrected versions of the FIRST Robotics Competition parts
...
I guess I'll try changing the version number in the fzp files and do a push and see what happens. In theory that will update the pull request assuming the above is correct, but I'm still unclear on what I should be doing to keep my repositorys synced.
@vanepp 'git status' will tell you the local status. To get remote changes, a possible command is "git fetch --all"
After a 'git reset --hard b0235d3' you will still be able to recover everything that was already commited to git. For example it might be on a different branch. If not, you can usually access it with 'git reflog'
Create a new hopefully non conflicting pull request for the listed 5 parts. I ended up deleting my fritzing-part fork and re forking it because I had managed to corrupt the original repositories. I did get a git fetch upline and merge to update my local repository, but pushing it to my fritzing-parts repo on github didn't clear the conflict on my original pull request. Hopefully this will create a proper pull request with no conflicts and a git fetch upline and merge in future will keep my local repo in sync in future (we will see when someone else makes a change to parts I expect).