Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All s300 vals #219

Open
wants to merge 39 commits into
base: master
Choose a base branch
from

Conversation

AdamRJonesHPD
Copy link
Contributor

@AdamRJonesHPD AdamRJonesHPD commented Jun 10, 2021

@pablobuenaposada

Contains all S300v3 fields that I've been able to decode. Was having trouble showing all fields, a restart/rebuild fixed it.

All fields added were stimulated on the engine sim. I reserve the right to keep working on the conversion formulas :)

Please have a look and let me know your thoughts!

Copy link
Owner

@pablobuenaposada pablobuenaposada left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really nice work, thanks for this contribution.
Unfortunately, it's not that easy to merge this, first of all, because the tests are not passing (https://github.com/pablobuenaposada/HonDash/pull/219/checks), which is expected since you are sending more things through the websocket and tests need to be adjusted, no big, deal I will explain you what can we do with the issue of the tests.
The other thing is there are too many commits, normally you will expect only one commit per pull request, here we have around 30 with reverts in the middle that if I would merge it like this is going to pollute the git history.
Let's do something simpler, get one of those new values and just try to add it to the project, no frontend changes or other deviations, tests are most likely going to fail but I will cover them somehow, no problem, I just did something like this for the analogs that you can use it as example #222

Anyway, thanks, good job, I can fix all of this but I want your name on the commit and be more independent for next changes.

@@ -0,0 +1,15 @@
{
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can add the entire .vscode folder in gitignore so we don't push this type of files

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added .vscode/ to gitignore

@@ -0,0 +1,73 @@
{"data": {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this not needed to be commited

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries, this is resolved anyway, can delete altogether.

.gitignore Show resolved Hide resolved
setup.json Show resolved Hide resolved
src/backend/devices/ecu.py Show resolved Hide resolved
src/backend/devices/s300/constants.py Show resolved Hide resolved
src/backend/devices/s300/constants.py Show resolved Hide resolved
src/backend/devices/s300/s300.py Show resolved Hide resolved
@AdamRJonesHPD
Copy link
Contributor Author

"The other thing is there are too many commits, normally you will expect only one commit per pull request, here we have around 30 with reverts in the middle that if I would merge it like this is going to pollute the git history."

I'm good with this suggestion. What's the proper etiquette here? If I'm working on a branch for a while it's going to have at least a few commits. Do I finish, merge that branch back my master, and then submit a PR for the whole thing?

Regarding paring down to only one added field, should I stash my larger changes locally, or just comment out the others until we are ready to roll them in?

@pablobuenaposada
Copy link
Owner

"The other thing is there are too many commits, normally you will expect only one commit per pull request, here we have around 30 with reverts in the middle that if I would merge it like this is going to pollute the git history."

I'm good with this suggestion. What's the proper etiquette here? If I'm working on a branch for a while it's going to have at least a few commits. Do I finish, merge that branch back my master, and then submit a PR for the whole thing?

There's a way to squash commits before pull requesting, check google because is better explained there than I could do.
The idea is that you can do as many commits as you want locally for your clarity but just before pull requesting you squash them into one.
You could also still fix it for this one because you locally can squash and git push --force but I don't think is worth it this time.

Regarding paring down to only one added field, should I stash my larger changes locally, or just comment out the others until we are ready to roll them in?

you can leave this pull request/branch here for now, my suggestion would be to just create a new branch from master and add manually whatever new value you pick and try to make a pull request, at least until you get a full workflow completed on how to add changes in here.

@AdamRJonesHPD
Copy link
Contributor Author

Sounds good, thanks. I'll put some work into it today.

@pablobuenaposada pablobuenaposada force-pushed the master branch 5 times, most recently from 75faa58 to 7d59981 Compare November 9, 2024 21:54
@pablobuenaposada pablobuenaposada force-pushed the master branch 5 times, most recently from ea0f7e3 to 6d0e6f1 Compare January 5, 2025 16:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants