search

atigyi / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
0 stars 0 forks source link

google_iot_device: Clean up README.rst #4

Closed pfalcon closed 5 years ago

pfalcon commented 5 years ago

https://github.com/atigyi/zephyr/blob/google_iot_device_sdk_integration/samples/net/google_iot_device/README.rst, as it stands now, has a couple of improvements which could be made to it:

  1. It currently has very long lines, effectively a line per paragraph. But per Zephyr conventions, these files should have lines wrapped (at ~70 chars per line), to make them viewable with plain-text viewer.
  2. A few latest commits to this branch all change this README, it would be nice to git-squash all these related commits into one.

@atigyi, please let me know if you think it makes sense to do these changes, and if you could do that. Thanks!

atigyi commented 5 years ago

Hi @pfalcon, please take a look: https://github.com/atigyi/zephyr/commit/d5b7c77016b0c39e61f24e3388e0cdb5bd44e419.

atigyi commented 5 years ago

Probably upcoming changes should use branching and regular git PRs. What do you think?

atigyi commented 5 years ago

Also this change required git history change, which will need irregular steps in your clone. Probably you are aware of this, but something like this: https://stackoverflow.com/questions/9813816/git-pull-after-forced-update/18516367

pfalcon commented 5 years ago

Hi @pfalcon, please take a look: d5b7c77.

Very good, thanks!

Probably upcoming changes should use branching and regular git PRs. What do you think?

Yes, if it adds some new feature, or noticeably change existing code. At least, that's how I intend to submit my changes. But later, we still may need to squash related commits together, at the very least, at the time of submitting PR to Zephyr upstream. But I'm personally keen to keep even interim work clean, e.g. I think it's easier to work with e.g. 10-commit patchset, than 20/30-commit.

Also this change required git history change, which will need irregular steps in your clone.

I myself very well get used to rebase-based workflow, so no troubles on my side. Generally, it just takes to use git pull --rebase to pull the changes, instead of plain git pull. So, as long as you're ok with it either, we should be good, and definitely will save a bunch of time/effort later, when submitting the final PR upstream.

Thanks again!

pfalcon commented 5 years ago

And closing then.