Add --commits command line option

[sk-]

For CI, it would be great to have a --commits options that allows one to specify a comma separated list of commits id to track.

[honzajavorek]

I'd like to use this feature. I'm willing to contribute, but would probably need some pointers on what would be the best way to approach this.

[honzajavorek]

I did some research, but I'm not sure this will be easy.

[YBadiss]

Hi I am interested in this, more specifically in allowing the user to pass in a range of commits.

I have a version of the code which works with a new argument --since-commit so git lint can be invoked as git lint --since-commit master to lint all the changes between a given commit/branch/tag and HEAD.

@sk- I don't have much knowledge of mercurial so I am not adding that feature there. If you still take PRs I'll send you one in a couple days.

[mistercrunch]

@YBadiss mind sharing your solution? I'm looking for something that will fail CI builds if there's lint in the changeset.

[jombooth]

@mistercrunch I found a supremely kludgy approach to using git-lint to fail CI if there's new lint in a PR. I accomplished it by means of a Make target which stores the current commit hash, does a git soft reset back to the latest common ancestor of the branch in the PR and origin/master, runs the linter (since all the changes from the commits in the PR are now staged), then resets back to the current commit.

.PHONY: lint
lint:
        CURRENT_COMMIT=$$(git rev-parse HEAD)                           ;\
        CURRENT_BRANCH_NAME=$$(git rev-parse --abbrev-ref HEAD)         ;\
        ANCESTOR=$$(git merge-base $$CURRENT_BRANCH_NAME origin/master) ;\
        git reset --soft $$ANCESTOR                                     ;\
        pipenv run git lint                                             ;\
        EXIT_CODE=$$?                                                   ;\
        git reset --soft $$CURRENT_COMMIT                               ;\
        exit $$EXIT_CODE

This works on CI (tested on CircleCI), and locally as well. I'm still a little suspicious of what I'm doing with the git resets, but in my testing, it seems to be just fine. Let me know if this approach works for you!

[jombooth]

Also, @YBadiss if you wouldn't mind sharing your --since-commit solution, that'd be super helpful, because with it perhaps ^ would no longer be necessary :)

[sk-]

For the ones looking on how to integrate git-lint in a CI environment, I just integrated it into Travis CI, (see the .travis.yml config).

Basically you do:

git reset --soft ${TRAVIS_COMMIT_RANGE%...*} && git lint

A similar approach could be done in Circle CI using the environment variable CIRCLE_COMPARE_URL

[sk-]

The feature of accepting commits or a commit range is feasible and most of the infrastructure is already there.

The last-commit flag is implemented by passing around a single commit value, however that can also be a commit range.

The main change required would be to change git.modified_lines to expand the commit range into a list of commit ids.

Also we would need to double check whether the same approach applies for mercurial, if not the flag should work only for git.

[YBadiss]

@jombooth just saw this, since then a lot happened and somehow I never pushed that change anywhere. Will look into it again soon.

[timmartin19]

@sk- I've got something working that uses git rev-list to get the commits/diff in a variety of manners.

If you wanted everything on branch a but not branch b (for example, a PR) you'd do something like

git lint --git-diff 'a ^b'

If you wanted a commit range

git lint --git-diff 'aeb273ab9..8203bce9089'

Basically if it works with git diff-tree and git rev-list it'll work. If you'd like I can clean it up, write some tests, and submit a PR