[jira] [Commented] (OFBIZ-11304) Install a Checkstyle pre-push (on every committer machine?)

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134147#comment-17134147 ]

Jacques Le Roux commented on OFBIZ-11304:
-----------------------------------------

HI Aditya,

This is what I get for a checkout:

{noformat}
C:\projectsASF\Git\ofbiz-framework>git checkout
M       build.gradle
M       framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java
Your branch is up to date with 'origin/trunk'.
{noformat}

That makes sense and is not blocking. Also with

{noformat}
$ git.exe checkout release18.12
error: Your local changes to the following files would be overwritten by checkout:
        build.gradle
        framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java
Please commit your changes or stash them before you switch branches.
Aborting
{noformat}

Again that makes sense and is not blocking.

With rebase, I get:

{noformat}
$ git rebase remotes/origin/trunk
error: cannot rebase: You have unstaged changes.
error: Please commit or stash them.
{noformat}

Again that makes sense and is not blocking.

After a no-verify:

{noformat}
C:\projectsASF\Git\ofbiz-framework>git commit --no-verify -a -m"test"
[trunk 746c1041c4] test
 2 files changed, 34 insertions(+), 3 deletions(-)

C:\projectsASF\Git\ofbiz-framework>git checkout
Your branch is ahead of 'origin/trunk' by 1 commit.
  (use "git push" to publish your local commits)

C:\projectsASF\Git\ofbiz-framework>git rebase remotes/origin/trunk
Current branch trunk is up to date.
{noformat}

Again that makes sense and is not blocking.


If I use git rebase -i, I get to this in my system editor:
{noformat}
pick 746c1041c4 test

# Rebase ed6a6fe3d3..746c1041c4 onto ed6a6fe3d3 (1 command)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
{noformat}

I let it like that, then exited. I did not test all options. Again that makes sense and is not blocking. I made a hard reset and all is OK with me.

So I agree we have no problems with that. At least so far and if ever we cross issues they should not be

> Install a Checkstyle pre-push (on every committer machine?)
> -----------------------------------------------------------
>
>                 Key: OFBIZ-11304
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-11304
>             Project: OFBiz
>          Issue Type: Sub-task
>    Affects Versions: Trunk
>            Reporter: Jacques Le Roux
>            Priority: Minor
>             Fix For: Upcoming Branch
>
>
> The ofbizTrunkFrameworkPlugins build fails when a lint error is detected by the check gradle task. It's "hard" to exactly know from where lint errors  come among all still present.
> I think we should rely on a Checkstyle pre-commit hook like https://gist.github.com/davetron5000/37350 to complement tasks.checkstyleMain.maxErrors. This pre-commit hook prevents to commit when a lint error is present in the commit.
> Every committer would have it installed locally and the problem would be gone with some committers good will. I started a discussion about it at https://markmail.org/message/guxbsvdkzky7gtdx. Jacopo made the same proposition years ago: https://markmail.org/message/gkgmko4axj3vtnv3

--
This message was sent by Atlassian Jira
(v8.3.4#803005)