Document checkpatch.sh arguments with examples.

[davids5]

from #448 (comment)

[xiaoxiang781216]

@davids5 is the document in this patch enough?
#516

[davids5]

No Examples are missing.

define "commit list"
is it
checkpatch.sh -g 2343..9011
or
checkpatch.sh -g e7460a2ca740068c09f37b41552140d8621dd13e**,** bba8aac22d01d4f966396bd6b5bcbeb9b0e3f220
or is it
checkpatch.sh -g e7460a2ca740068c09f37b41552140d8621dd13e bba8aac22d01d4f966396bd6b5bcbeb9b0e3f220

[xiaoxiang781216]

If user use git, he already know how to specify commit id, should we put so much boring info?

[davids5]

Are all the above correct?

[davids5]

Yes. What about a "patch list". Is it a file with the patches listed in it or a list of file names. You are to close to the problem to see what is missing.

[xiaoxiang781216]

Are all the above correct?

Of course, if git accept, checkpatch.sh will accept, do you want me to duplicate the full gitrevisions?

GITREVISIONS(7)                                                          Git Manual                                                          GITREVISIONS(7)

NAME
       gitrevisions - specifying revisions and ranges for Git

SYNOPSIS
       gitrevisions

DESCRIPTION
       Many Git commands take revision parameters as arguments. Depending on the command, they denote a specific commit or, for commands which walk the
       revision graph (such as git-log(1)), all commits which are reachable from that commit. For commands that walk the revision graph one can also specify
       a range of revisions explicitly.

       In addition, some Git commands (such as git-show(1)) also take revision parameters which denote other objects than commits, e.g. blobs ("files") or
       trees ("directories of files").

SPECIFYING REVISIONS
       A revision parameter <rev> typically, but not necessarily, names a commit object. It uses what is called an extended SHA-1 syntax. Here are various
       ways to spell object names. The ones listed near the end of this list name trees and blobs contained in a commit.

       <sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e
           The full SHA-1 object name (40-byte hexadecimal string), or a leading substring that is unique within the repository. E.g.
           dae86e1950b1277e545cee180551750029cfe735 and dae86e both name the same commit object if there is no other object in your repository whose object
           name starts with dae86e.

       <describeOutput>, e.g. v1.7.4.2-679-g3bee7fb
           Output from git describe; i.e. a closest tag, optionally followed by a dash and a number of commits, followed by a dash, a g, and an abbreviated
           object name.

       <refname>, e.g. master, heads/master, refs/heads/master
           A symbolic ref name. E.g.  master typically means the commit object referenced by refs/heads/master. If you happen to have both heads/master and
           tags/master, you can explicitly say heads/master to tell Git which one you mean. When ambiguous, a <refname> is disambiguated by taking the first
           match in the following rules:

            1. If $GIT_DIR/<refname> exists, that is what you mean (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD and
               CHERRY_PICK_HEAD);

            2. otherwise, refs/<refname> if it exists;

            3. otherwise, refs/tags/<refname> if it exists;

            4. otherwise, refs/heads/<refname> if it exists;

            5. otherwise, refs/remotes/<refname> if it exists;

[xiaoxiang781216]

Yes. What about a "patch list". Is it a file with the patches listed in it or a list of file names. You are to close to the problem to see what is missing.

A list of file name of course:
checkpatch.sh *.patch
Anyway, if you think the usage isn't clear, please send a PR.