errors for ops not meaningful for 'nanotime' + handle NA, NaN, Inf, -Inf

[lsilvest]

No description provided.

[eddelbuettel]

I'll merge, but I'll go back to just 'squash merge' because our trees have aligned to poorly in the past.

Ok?

[lsilvest]

Yes, absolutely. I'll read about why I was forced to do yet another merge after my changes. Do you have any other suggestions ? Should I throw away my fork and start a new one?

[eddelbuettel]

I manage to create mini-versions of the problem just by myself between laptop and server (or a third machine).

I think the key really is simply to remain current, and to branch cleanly from master. If that branch then gets merged all is well. Which is pretty doable in a calmer repo like this where it is only you and me, and rarely at the same time. But I do have colleagues who manage to create pretty impressive spaghetti patterns at work merging between branches and what not...

Doesn't matter greatly but also not that hard to get right.

[eddelbuettel]

Otherwise, ready for a new release?

[eddelbuettel]

Josh pipes in via private slack:

The answer to Leonardo's question about Git is that he's likely not sync'ing with your repo before he starts committing again, so he's missing the merge commit from his prior PR.

[joshuaulrich]

Josh pipes in via GitHub comments:

You need to configure and sync your fork to avoid these types of merge commits. I usually update via git fetch --all, then git merge --ff-only upstream/master. The merge command will fail if my local master is behind upstream/master. In that case, I'll run git rebase -i master upstream/master.

Here's a decent article that explains forks and upstreams, and has a cool bash function that tells you how many commits ahead/behind your fork is.

[lsilvest]

Thanks for the tips!

[lsilvest]

Yes, I think this version is good enough for a release. I didn't find anything else while playing around with nanotime.

[eddelbuettel]

Thanks @joshuaulrich those are good. Added to my (old) ~/git/README.txt.

Something that has always worked for me from this is

• add a tracking master (cf https://help.github.com/articles/adding-a-remote)
  git remote add --track master parentrepo https://github.com/someUser/someRepo.git

followed by git pull --all; git merge parentrepo. By having --track master here I don't need it in the subsequent merge command as you do.