search

Cacti / documentation

Documentation for Cacti, Spine, RRDProxy and more
62 stars 52 forks source link

Update spikekill doc #83

Closed riversdev0 closed 4 years ago

netniV commented 4 years ago

Changes looked good. I had some spare moments before bed so I updated your branch with more style changes. Some that had crept in elsewhere but corrected now and the bin/check_markdown_style.sh returns no issues 👍

You may notice that I rejigged your lists slightly and broke up some of the paragraphs to highlight the important of some of the statements (such as the RRA-DS older-to-newer removal), plus make the example elements clearer.

riversdev0 commented 4 years ago

So now that the 'develop' branch is a few commits ahead of my personal forked repository, what am I supposed to do? The last few times, I deleted my entire fork and re-forked the repo. Then yesterday I decided to try merging the Cacti repo into my repo which produced a confusing result because it counted the merge as a commit and said I was 1 commit ahead and 1 commit behind even though the code was made identical by performing the PR. What's the proper way to do this? Shouldn't there just be a 'Refresh Fork' option that brings you up to current?

netniV commented 4 years ago

You should just be able to pull on the develop branch to your local develop branch (git pull upstream/develop) and remove the branch. As you find changes you want, again create a branch, rinse and repeat.

If you haven't set the upstream repo, you will need to add it as a remote to pull in those references (it doesn't usually do that for you automatically unfortunately). Effectively, the full steps taken are something like:

branch->changes->commit->push->PR->upstream(merge)->checkout develop->pull->delete branch

since the changes between the HEAD on your develop and the HEAD of develop on the upstream should be the same, you can even use the fast forward only option to ensure you are in sync with upstream develops changes.

When I work on repos I have direct access to/own, I go a bit more convoluted as I commit changes, attempt to push and if the origin has changes, I rebase my local on the origin which places my latest changes at the end allowing me to push again.

Git is very flexible in its ways of working, some good some bad. You can actually use GitHub's website to bring the latest changes on your own repo.