Patch Set 7:

>2. Add some text, then check "Compute Change-Id", then check "Signed-off" -> extra line break between Change-Id and Singed-off.

That is not a bug from this change. See the next "Needed by" commit that fixes that issue.

>3. Add a Commit-Id, then remove it from the text box manually -> The "Compute Change-Id" button remains checked and the Change-Id is created upon commit, but that's probably not what the user would have expected unless they looked at the checkbox really hard...

From my side that was intentional, but I understand people might disagree and I might change my mind.

>4. Add some text, then check "Compute Change-Id", then check "Amend previous commit" -> you end up with two Change-Ids in the message (if previous had one); if you then uncheck "Compute Change-Id", only the first one will be removed and the check box will still be selected; if you click the second time, the second Change-Id will be removed and the checkbox unchecked.

I noticed this one and I'm not sure how to handle that because there I see no automatic logic to select which change-id to prune. I guess we should keep the first one.

I think 2. should be fixed (hopefully not too difficult).

>I believe issues 3 and 4 can only be solved if we put the Change-Id in some extra field (similar to Author and Committer) instead of directly editing the message. For the time being, though, I would say the behavior is good enough.

We will need a smarter editor with highlighting, spell checking and an error-field and some plugin mechanism for validating the format. The whole point of inserting the change-id before computing it was to show where it would go. We might also simply compute a random number and insert it instead of trying to emulate the git hook bit-by-bit.