Style changed applied.

I've updated the comments too. Is this too much, or just right?

I've updated the comments too. Is this too much, or just right?

I think it's a bit too much now (previous comment was enough). Also - changing the comment is not quite in sync with the title of the last commit.

Ok. I'll update.

What I was hinting at was that also we can't use setObject(index, obj, sqlType, lengthOrPrecision) (http://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#setObject(int,%20java.lang.Object,%20int,%20int))

But the comments might be confusing. I'll update it to the first original text.

Basically - setObject without extra args is simpler that the other overrides with extra args. So I suppose that's why we prefer it instead of other longer options.

Updated.

I've reused the commit comment from the first commit as the title and added sub text.

Do you chaps have any standards for commit comments?

Do you chaps have any standards for commit comments?

No hard standard right now but the message should describe the change in the commit. E.g. it should help to understand what's going on when you look at https://github.com/dbfit/dbfit/pull/322/commits

Since most commits after 1st one here are not something new but are fix-ups on top of the initial one: it's good to squash them in single commit.

http://git-scm.com/book/en/Git-Tools-Rewriting-History

Since most commits after 1st one here are not something new but are fix-ups on top of the initial one: it's good to squash them in single commit.

http://git-scm.com/book/en/Git-Tools-Rewriting-History

Besides that, looks good to me.

Since most commits after 1st one here are not something new but are fix-ups on top of the initial one: it's good to squash them in single commit.

I've tied git rebase -i HEAD~3 then selected fixup for the last 2 commits. The git status tells me:

Your branch and 'origin/handle-nulls-in-teradata-fixture-tables' have diverged, and have 1 and 3 different commits each, respectively.

I can't git push because:

! [rejected] handle-nulls-in-teradata-fixture-tables -> handle-nulls-in-teradata-fixture-tables (non-fast-forward)
error: failed to push some refs to 'https://github.com/dbfit/dbfit.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.

And if I git pull then the commits from origin get re-added to my commit history.

Can I still rebase now I've pushed the first 3 commits?

I think your rebase was OK. But after that, since it indeed rewrites history, the way to push is via --force option.

Right, I think I've finally got it right.

👍