H-Bridge with L298N motor driver

I was using the command line from a cygwin terminal (so essentially Linux except on Windows.)

I don’t have them any more, as I deleted the pull request and the branch. As I recall, I backed off a commit (which is probably my mistake) to make a change. When I made the change and pushed my local branch I got the reject message in the post above. When I fumbled around some more (probably trying the git pull they suggested) it managed to lose what branch it was dealing with and started asking what branch I wanted to merge with. At that point I figured it was a lost cause and wrote the whole thing off and closed and deleted the pull request in fritzing-parts on github and deleted the local branch. I don’t know if my remote branch is now screwed up , if so I will do my usual solution and delete the upline repository, and reclone it on both github and locally. As noted above the modified files for the change are in the Dual_VNH2SP30_Motor_Driver-files.fzpz file above (which isn’t a fzpz but a zipped copy of the repository files) if you want to make a change request. I expect that if I opened a new pull request I could probably (if after deleting my local and upline repositories which I don’t want to do right now as I have a couple of other pull requests open!) get the files to upload correctly as long as I then don’t need to make any changes. My best bet appears to be to ignore github and just publish the parts in the forum as github and I don’t get along. I am having no success (but lots of frustration!) in figuring out how it is supposed to work.

Peter

Yes, try to “cancel” a commit is a bit more tricky. The easy way would be to undo the changes in your files and make a new commit. There will be two commits, but it does not matter too much. Another way could be to go to the previous commit and create a new branch. After that, you can modify the files and push the changes to the remote repository (in github). And in the GitHub website, cancel the original pull request and open a new one with the new branch.

I can still see your pull request in GitHub: Add new part Dual_VNH5019_motor_driver by vanepp · Pull Request #362 · fritzing/fritzing-parts · GitHub

I think that you do not need to do that. You can go back to the develop branch (git checkout develop) and create a new branch and switch to it (git checkout -b new_branch). Then, you will be in the branch new_branch but the files will be the same as in the develop branch. After that, you can modify your files, commit and push your changes to the remote repository in GitHub as many times as necessary. When you think your files are ready to be committed to the official repository, you go to GitHub and open a pull request. if you commit more changes to your remote repository they will be added automatically to the pull request.

The old branch will be ignored and you could delete it or not. It does not matter too much.

I can do that, but it would be great if you do it directly. You are creating a lot of parts and it would be great to integrate them in Fritzing. I cannot do that for all of them and it takes me a while to do it, especially if they need to be obsoleted.

I know git is annoying and frustrating, but I am happy to assist you. We could organize an online meeting where we commit the changes together. You can also try SourceTree, which gives you a GUI where you see the changes to commit, the branches in a tree way and you can change between branches by double clicking on them, see below.


In this moment, I created a branch called “transitory_sim_parts” where I am working. This branch is based on the develop branch (commit c53679d1) and I have not committed anything to this branch, but I can see that there are uncommitted changes in the files with respect to the develop branch.

If I click on the uncommited changes, I can observe all the files that have changed, see below. In this case, I added a new file called dcpower_pulse.fzb into the core folder and I have modified the file in bins/more/sim.fzb. When I click on these files, I can see what I have modified. In the example, I added a new part to the simulation bin.

When I am ready to commit, I press commit in SourceTree and I choose the changes that I want to commit. In the case below, I have chosen to stage all the modifications, but I could avoid some files or specific changes in the file. After that, I write the commit message and press commit.

When this is done, I can go to the history and see that commit added to the tree. When I click on a commit I can see the changes made by that specific commit:

For example, if I click on the last commit on the develop branch, I can see that I modified two resistor files, where I added the symbol to the property and remove the showInLable=“yes”.

If I want to change to the develop branch, I just need to double-click on the develop branch. Notice that the commit is in bold and the develop branch is also bolded at the left pane.

I hope that this helps you, but again, I am more than welcome to do it together in a real example on your computer. Once you get used, it is not as frustrating.

That is one for a new part (the replacement for the original motor driver) and is why (along with the obsolete.py pull request) I don’t want to disturb github til they get merged (if they do!) I hadn’t realized that I could create a new branch and have it commit changes to the old branch’s pull request, I would have thought it being a new branch would create a new pull request and confuse things even more. I’ll have a look at source tree and see if I can get that running here.

edit:

I started out to make a pull request for the Dual_VNH2SP30_Motor_Driver part with the intent of making a pull request for it, and made the mistake of doing a

git diff develop Dual_VNH2SP30_Motor_Driver_2

which turns up a potential problem in obsolete.py. It looks like either something I have done or something in mindom is reformatting the xml when it is written and thus the git diff is showing lots of unexpected differences. So now I need to go back and check obsolete.py (and potentially modify it’s pull request) and maybe redo the Dual_VNH2SP30_Motor_Driver obsolete before submitting a pull request. Good in one way I suppose, identified a potential problem in obsolete. py.

Edit:

OK, I have resolved my issues and made a pull request for the Dual_VNH2SP30_Motor_Driver on github so hopefully it will occur.

Peter

Thank you!!! i was looking for a better version!!

Excellent! Send me a mail if you run into other issues.