#6401 Support to "alwaysSignOff" commits

[JonasHelming]

Signed-off-by: Jonas Helming jhelming@eclipsesource.com

What it does

• fix Support to "alwaysSignOff" commits (via a preference) #6401: It add a preference to "auto sign off" on CTRL+ENTER in the SCM view

How to test

turn the preference on (under Git) and commit via CTRL+ENTER. Check the the commit is signed off

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[vince-fugnitto]

@JonasHelming please take a look at the failing CI.

---

The error comes from a missing binding during the test:

theia/packages/git/src/browser/git-repository-provider.spec.ts

Lines 93 to 95 in e0074c5

	testContainer = new Container();
	testContainer.bind(GitRepositoryProvider).toSelf().inSingletonScope();
	testContainer.bind(Git).toConstantValue(mockGit);

Adding the binding for GitPreferences worked for me locally:

...
testContainer.bind(GitPreferences).toConstantValue(<GitPreferences>{});
...

[AlexTugarev]

Hi @JonasHelming! While this seems to work as advertised, I think it's confusing that cmd+enter behaves different to the ✔️ Commit button in that regard.

Why not aligning with vscode and implementing a general git.alwaysSignOff setting?

[kittaakos]

aligning with vscode and implementing a general git.alwaysSignOff

👍

• https://github.com/microsoft/vscode/blob/e02e20c3ced82314a82f04f68674bc81e8e43c86/extensions/git/package.json#L1348-L1353
• https://github.com/microsoft/vscode/blob/e02e20c3ced82314a82f04f68674bc81e8e43c86/extensions/git/src/commands.ts#L1318-L1320
• https://github.com/microsoft/vscode/blob/e02e20c3ced82314a82f04f68674bc81e8e43c86/extensions/git/src/git.ts#L1187-L1189
• https://github.com/microsoft/vscode/blob/e02e20c3ced82314a82f04f68674bc81e8e43c86/extensions/git/src/git.ts#L1199

[JonasHelming]

Hey,

thanks for the feedback, I will have a look at the failing test cases.
About the functional feedback: I agree that a "alwayssigneoff" preference setting is more consistent with VS Code. However, I personally find that a bit confusing in VS Code, because in the menue, you see

• Commit Staged
• Commit Staged (sign off)
  But both actually do the same. Why does the menu then even show both options if the setting is turned on? Therefore, I decided to influence the default action on CTRL+ENTER rather then "alwayssignoff". What is the sense of opening the menu and then clicking on commit (not on commit(sign off)) and still exspecting to sign off?

Maybe a potential solution is to show in the commit message text field "Message (Ctrl+Enter to commit (signed off) on {$branch}?

Another potential solution is to introduce both preferences.

Finally, if you dislike the "CTRL+ENTER" only approach, I can rework it to match VS Code exactly although as mentioned, I find that more confusing.

What do you think?

[akosyakov]

It would be good to be aligned with VS Code, especially we are going to drop native extension eventually in favor of VS Code one.

[JonasHelming]

I have no idea, why the build on Mac fails ...

[akosyakov]

restarted the job, was too many requests to GitHub to download vscode-rigrep

[akosyakov]

It does not help :( is it because a fork don't get our github tokens? cc @marcdumais-work ?

[vince-fugnitto]

restarted the job, was too many requests to GitHub to download vscode-rigrep

The same happens in this PR :( #6480

[marcdumais-work]

It does not help :( is it because a fork don't get our github tokens? cc @marcdumais-work ?

Yes, exactly this

https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-settings
These variables are not automatically available to forks.

[akosyakov]

ok, so then we can ignore the build failure and merge?

[marcdumais-work]

ok, so then we can ignore the build failure and merge?

In case of doubt we can restart the failing job - it will pass eventually.

[vince-fugnitto]

ok, so then we can ignore the build failure and merge?

In case of doubt we can restart the failing job - it will pass eventually.

I've manually restarted the build, the CI is now all green :)

[akosyakov]

@AlexTugarev @kittaakos Could you finish the review please? You had some comments above. Were they addressed? If so, please approve and merge.

[kittaakos]

The code looks good and it works as expected. It is good to merge 👍

Thank you for your help, @JonasHelming!

I have verified the changeset in Gitpod by manually adjusting both .vscode/settings.json and .theia/settings.json files, committing to the local repo, and checking the git log.