search

RobTillaart / I2C_EEPROM

Library for I2C EEPROM - 24LC512, 24LC256, 24LC64/32/16/08/04/02/01.
MIT License
91 stars 20 forks source link

Added documentation for I2C_eeprom_cyclic_store #11

Closed Titantompa closed 3 years ago

Titantompa commented 3 years ago

In response to issue RobTillaart/I2C_EEPROM#10

RobTillaart commented 3 years ago

Documentation looks good to get it started. If you want I can merge this version.

Titantompa commented 3 years ago

Documentation looks good to get it started. If you want I can merge this version.

Yes, thanks! Please give me feedback if there is something obvious missing!

Titantompa commented 3 years ago

Also, it seems like something gets weird when you do squash merges. I'm very new at github so there are things I need to figure out. I should probably work in different branch than master in my own fork....

RobTillaart commented 3 years ago

The advantage of squashing is that the history / log does not get full of tiny commits. It especially removes fix over fix over fix commits

Drawback is that it is harder to reverse an individual commit, but after a dozen or so this can become hard anyway.

You should never develop in the master branch as that is the version you know that works. Only if a "develop" branch is stable it should be merged with master.

You can "reset" your master branch also by checkout another branch (it has full history of master) revert your master to some commit in history then do a merge --squash another branch ans all those individual commits are gone

Checkout - https://git-scm.com/book/en/v2

Titantompa commented 3 years ago

The advantage of squashing is that the history / log does not get full of tiny commits. It especially removes fix over fix over fix commits

Drawback is that it is harder to reverse an individual commit, but after a dozen or so this can become hard anyway.

You should never develop in the master branch as that is the version you know that works. Only if a "develop" branch is stable it should be merged with master.

You can "reset" your master branch also by checkout another branch (it has full history of master) revert your master to some commit in history then do a merge --squash another branch ans all those individual commits are gone

Checkout - https://git-scm.com/book/en/v2

Yeah, thanks! I just expected that, when I merged the upstream back into my fork, that all the commits would be folded away as already having been merged into the upstream. But given it a second thought, that is not the way git works so I shouldn't have been surprised. I guess it becomes best practice to close (remove) merged branches when you do squash merges so that those interim commits don't pop back. It is already best practice to not continue on an already merged branch anyways, so it shouldn't be an issue. I just continued an old pattern we used in Bitbucket, which works a little differently with forks.

RobTillaart commented 3 years ago

I still forget to squash sometimes and indeed as you say, new issue should be a new branch split of the master every time. After a few big screw ups I finally learned to use git a bit better :)

You could make a dummy repo just to play around with git and have fun (sort of)