initial stab at an user update role and test

[lrvick]

No description provided.

[lrvick]

Any ideas on how to go about deploying this?

@drGrove @daurnimator @RyanSquared

[drGrove]

It's in the K8s cluster, no?

[drGrove]

It's in the K8s cluster, no?

So we don't have a good way of deploying schema updates just yet. You need to connect to the database directly and apply your patches

[daurnimator]

In addition to addressing #57 (comment) please partially squash your commits down to logical increments.

[lrvick]

Partial squashes are not possible without destroying signatures. I can either squash the whole thing as one commit and destroy all history here, or ship it as is.

Personally I prefer highly verbose commits that show the real time-frame and iteration of a set of changes to see a development thought process in the future if I am investigating something.

[daurnimator]

Partial squashes are not possible without destroying signatures.

Of course. Your new squashed commits should be newly signed.

I can either squash the whole thing as one commit and destroy all history here, or ship it as is.

You can squash some commits into each other.
e.g. git rebase -i origin/master and change some of them to fixup.

Personally I prefer highly verbose commits that show the real time-frame and iteration of a set of changes to see a development thought process in the future if I am investigating something.

The git repo doesn't need to be a permanent record of your exploratory learning.
As a reviewer (both of the PR and in future reviewing the entire repo) I want to see small succint commits that explain what they do.... and that aren't immediately un-done in a following commit (at least without a release in-between).

[lrvick]

Git history should be immutable. Who cares how many commits it is.

In a shared document like a Google doc, do we go through the history and clean up all the little edits?

Also if there had been three authors in this branch, what would we do then? Would I squash all other peoples changes too and sign for them?

This feels like just adding a lot of extra work with no gain.

[KellerFuchs]

This feels like just adding a lot of extra work with no gain.

The gain is readability. The point of having version control is being able to see the sequence of changes that led from one state to another, and the point of commit messages is to document the intent of those changes.

So, yeah, I'd argue it's pretty important to make that documentation readable. =^.^'=