Coder Social home page Coder Social logo

git-lint-branch's People

Contributors

avik-pal avatar focalchord avatar jiviteshjain avatar juped avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

Forkers

jiviteshjain

git-lint-branch's Issues

Repository detection

The skeleton project currently opens a git repository in the current directory. Real git commands work from anywhere in a repository's work tree (and the ones that don't involve work trees work from anywhere in the repository too). See if pygit2 has a mechanism to do this first (I think it does); if not, write a simple one.

Multi-commit linters

Multi-commit linters are tougher than single-commit linters. I think they should get a fresh copy of the pygit2 walker and use it and/or the commit objects themselves to walk the log in their own style. However, it's possible that we might need more involved operations and data models. This requires some design forethought.

Maintainer configuration file

I'm thinking .git-lint-branch in the repository root (or a similar name) is good. Should be INI or TOML to match more or less closely with .gitconfig's format. This should be able to specify linters to run, options to linters that support them, and what warning level to apply to each linter.

Pretty print single commit linter outputs

With multiple linters producing output per commit, the output becomes hard to read.

  • A --no-verbose or similar option should silence help messages.
  • The commit data should include the commit message title and be printed only once per commit, with separators.
  • Color code according to severity

Testing

Maybe we should make a disconnected commit graph in the repository with a fake project history with some messy branches to test our linters against.

Warning levels

Part of the output of a linter should be the warning level: we can provide defaults in the linter, overridable by .git-lint-branch files. Maybe the following:

  • notice
  • caution
  • warning
  • fail (not in any defaults, just for maintainers to use)

Single-commit linters

These should be the easiest to represent - linters that only look at a single commit. In the overall program flow, we should walk the commits once and check each one with all single-commit linters, then later each multi-commit linter can walk the branch in its own way individually. What we need is some kind of function or class interface that takes a pygit2 commit object and returns a lint result.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.