How to avoid whitespace being commit with github

前端 未结 3 1618
梦毁少年i
梦毁少年i 2021-02-04 21:10

I made a 2 lines of change but in git It shows more lines of changes because of whitespace. Its very difficult for us to review the exact code changes.

The below are the

相关标签:
3条回答
  • 2021-02-04 21:31

    You now can setup a GitHub Action which will, when getting a new commit or a pull request, will fail if there is any whitespace issue.

    Git itself illustrates that automation process with Git 2.30 (Q1 2021).

    See commit 32c83af (22 Sep 2020) by Chris. Webster (webstech).
    (Merged by Junio C Hamano -- gitster -- in commit 1a42a77, 27 Oct 2020)

    ci: github action - add check for whitespace errors

    Signed-off-by: Chris. Webster
    Reviewed-by: Jeff King

    Not all developers are aware of [git diff --check](https://github.com/git/git/blob/32c83afc2c69aa51b82aa223f2099389f1f0be0a/Documentation/diff-options.txt#L415)<sup>([man](https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---check))</sup> to warn about whitespace issues.
    Running a check when a pull request is opened or updated can save time for reviewers and the submitter.

    A GitHub workflow will run when a pull request is created or the contents are updated to check the patch series.
    A pull request provides the necessary information (number of commits) to only check the patch series.

    To ensure the developer is aware of any issues, a comment will be added to the pull request with the check errors.

    You can see here the .github/workflows/check-whitespace.yml script

    It starts on pull request:

    on:
      pull_request:
        types: [opened, synchronize]
    

    It will use git log --check to detect if a commit includes any conflict markers or whitespace errors.


    With Git 2.30 (Q1 2021), the whitespace checker is more robust:

    See commit cba2504 (03 Nov 2020) by Johannes Schindelin (dscho).
    (Merged by Junio C Hamano -- gitster -- in commit 15486b6, 11 Nov 2020)

    ci: make the whitespace checker more robust

    Signed-off-by: Johannes Schindelin

    In 32c83afc2c69 ("ci: github action - add check for whitespace errors", 2020-09-22, Git v2.30.0 -- merge listed in batch #1), we introduced a GitHub workflow that automatically checks Pull Requests for whitespace problems.

    However, when affected lines contain one or more double quote characters, this workflow failed to attach the informative comment because the Javascript snippet incorrectly interpreted these quotes instead of using the git log(man) output as-is.

    Let's fix that.

    While at it, let's await the result of the createComment() function.

    Finally, we enclose the log in the comment with ... to avoid having the diff marker be misinterpreted as an enumeration bullet.

    0 讨论(0)
  • 2021-02-04 21:38

    You can use git diff -w | git apply --cached --ignore-whitespace as mentioned here

    EDIT: After you make any change, run
    git diff -w | git apply --cached --ignore-whitespace
    then
    git commit -m "your message"

    0 讨论(0)
  • 2021-02-04 21:47

    Another way to look at the problem is to be more cautious with the way you stage your changes.

    In your above example you're using two very broad sweeping ways to search for changes in your codebase before committing.

    git add .
    git commit -am "changes"
    

    The . parameter for add is already staging all detected changes (not exactly, see the excellent answers here for more details), but on top of that you're using the -a parameter for commit, which I'd describe as redundant overkill, since you're staging ALL changes AGAIN.

    Your context may make my following advice more or less practical, but you might consider adding your changed files "manually" :

    # check your changes (at this point, whitespace differences should not show up)
    git status
    
    # let's assume the above line showed changes in 3 files
    git add <path/to/file1> <path/to/file2> <path/to/file3>
    
    # then commit without staging parameter
    git commit -m "changes"
    

    And if the process seems tedious to you, keep in mind that :

    • You can copy and paste paths straight from the right above status output, which makes it quick
    • There is also an interactive mode invoked with add -i, which allows you to iteratively look at changes to decide what's to be actually staged.
    0 讨论(0)
提交回复
热议问题