Conflicting tags can prevent buildman from building two series which exist
one after the other in a branch. There is no reason not to allow this sort
of workflow with buildman, so ignore conflicting tags in buildman.

Change-Id: I2231d04d8684fe0f8fe77f8ea107e5899a3da5e8
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>

The git config parameter log.decorate is quite useful when working with git.
Patman, however can not handle the decorated output when parsing the commit.
To prevent this use the '--no-decorate' switch for git-log.

Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Acked-by: Simon Glass <sjg@chromium.org>

For some series with lots of changes it is annoying that duplicate change
log items are not caught. It is also helpful sometimes to sort the change
logs.

Add a Series-process-log tag to enable this, which can be placed in a
commit to control this.

The change to the Cc: line is to fix a checkpatch warning.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>

Especially with the Linux kernel, it takes a long time (a minute or more)
to test-apply the patches, so patman becomes significantly less useful.
The only real problem that is found with this apply step is trailing spaces.
Provide a -a option to skip this step, for those working with clean patches.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>

Patman's regular expression for detecting the start of a
commit in a git log was a little simplistic and could be
confused if the git log itself had the word "commit" as
the start of a line (as this commit does).  Make patman
a little more robust.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

Often it happens that patches include tags which don't have aliases. It
is annoying that patman fails in this case, and provides no option to
continue other than adding empty tags to the .patman file.

Correct this by adding a '-t' option to ignore tags that don't exist.
Print a warning instead.

Since running the tests is not a common operation, move this to --test
instead, to reserve -t for this new option.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>

These tags are used by Gerrit, so let's ignore all of them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>

A few of the help messages are not quite right, and there is a typo
in the README. Fix these.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>

This comment is less than helpful. Since multiple tags are supported, add
an example of how multiple tags work.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>

At present something like:

   Revert "arm: Add cache operations"

will try to use

   Revert "arm

as a tag. Clearly this is wrong, so fix it.

If the revert is intended to be tagged, then the tag can come before
the revert, perhaps. Alternatively the 'Cc' tag can be used in the commit
messages.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>

checkpatch has a new type of warning, a 'CHECK'. At present patman fails
with these, which makes it less than useful.

Add support for checks, making it backwards compatible with the old
checkpatch.

At the same time, clean up formatting of the CheckPatches() output,
fix erroneous "internal error" if multiple patches have warnings and
be more robust to new types of problems.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>

The cover letter is sent to everyone who is on the Cc list for any of
the patches in the series. Sometimes it is useful to send just the cover
letter to additional people, so that they are aware of the series, but
don't need to wade through all the individual patches.

Add a new Cover-letter-cc tag for this purpose.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>

Some versions of git don't seem to prompt you for the message ID that
your series is in reply to.  Allow specifying this from the command
line.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

Although "Reviewed-by:" is a tag that gerrit adds, it's also a tag
used by upstream.  Stripping it is undesirable.  In fact, we should
treat it as important.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Otavio Salvador <otavio@ossystems.com.br>
Acked-by: Simon Glass <sjg@chromium.org>

Add methods to find out the commits in a branch, clone a repo and
fetch from a repo.

Signed-off-by: Simon Glass <sjg@chromium.org>

We normally read from the current branch, but buildman will need to look
at commits from another branch. Allow the metadata to be read from any
list of commits, to provide this flexibility.

Signed-off-by: Simon Glass <sjg@chromium.org>

Make raise_on_error a parameter so that we can control which commands
raise and which do not. If we get an error reading the alias file, just
continue.

Signed-off-by: Simon Glass <sjg@chromium.org>

Rather than returning a list of things, return an object. That makes it
easier to access the returned items, and easier to extend the return
value later.

Signed-off-by: Simon Glass <sjg@chromium.org>

This adds a new library on top of subprocess which permits access to
the subprocess output as it is being generated. We can therefore
give the illusion that a process is running independently, but still
monitor its output so that we know what is going on.

It is possible to display output on a terminal as it is generated
(a little like tee). The supplied output function is called with all
stdout/stderr data as it arrives.

Signed-off-by: Simon Glass <sjg@chromium.org>

Rather than the rather dull colours, use bright versions which normally
look better and are easier to read.

Signed-off-by: Simon Glass <sjg@chromium.org>

It is easy to detect whether or not the process is connected to a terminal,
or piped to a file. Disable ANSI colours automatically when output is
not to a terminal.

Signed-off-by: Simon Glass <sjg@chromium.org>

To make it usable in git trees not providing a patch checker
implementation, add a command line option, allowing to suppress patch
check. While we are at it, sort debug options alphabetically.

Also, do not raise an exception if checkpatch.pl is not found - just
print an error message suggesting to use the new option, and return
nonzero status.

   . unit test passes:
    $ ./patman  -t
    <unittest.result.TestResult run=7 errors=0 failures=0>
   . successfully used patman in the autotest tree to generate a patch
     email (with --no-check option)
   . successfully used patman in the u-boot tree to generate a patch
     email
   . `patman --help' now shows command line options ordered
     alphabetically

Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Acked-by: Doug Anderson <dianders@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

The settings modules now has doctests, so run them.

Signed-off-by: Doug Anderson <dianders@chromium.org>

There are cases that we want to support different settings (or maybe
even different aliases) for different projects.  Add support for this
by:
* Adding detection for two big projects: U-Boot and Linux.
* Adding default settings for Linux (U-Boot is already good with the
  standard patman defaults).
* Extend the new "settings" feature in .patman to specify per-project
  settings.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

This patch adds support for a [settings] section in the .patman file.
In this section you can add settings that will affect the default
values for command-line options.

Support is added in a generic way such that any setting can be updated
by just referring to the "dest" of the option that is passed to the
option parser.  At the moment options that would make sense to put in
settings are "ignore_errors", "process_tags", and "verbose".  You
could override them like:

 [settings]
 ignore_errors: True
 process_tags: False
 verbose: True

The settings functionality is also used in a future change which adds
support for per-project settings.

Signed-off-by: Doug Anderson <dianders@chromium.org>

For Linux the best way to figure out where to send a patch is with the
"get_maintainer.pl" script.  Add support for calling it from patman.
Support is added unconditionally for "scripts/get_maintainer.pl" in
case it is helpful for any other projects.

Signed-off-by: Doug Anderson <dianders@chromium.org>

If we're sending a cover letter make sure to CC everyone that we're
CCing on each of the individual patches.

Signed-off-by: Doug Anderson <dianders@chromium.org>

Currently we go through and generate the CC list for patches twice.
This gets slow when (in a future CL) we add a call to
get_maintainer.pl on Linux.  Instead of doing things twice, just cache
the CC list when it is first generated.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

The Linux kernel stores checkpatch.pl in the scripts directory.  Add
that to the search path to make things more automatic for kernel
development.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

Several of the patman doctests assume that patman was run with:
  ./patman

Fix them so that they work even if patman is run with just "patman"
(because patman is in the path).

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

The patman test code was failing because some extra spaces got
stripped when it was applied.  These spaces are critical to the test
code working.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>

Often a particular patch may change only for some versions of a series.
For versions where there is no change, issue a change log indicating
that (for example 'Changes in v4: None').

For such lines, don't add a blank line afterwards, to conserve space.
Use list.insert() instead of list = [item] + list.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>

The BRANCH= tag can be used to indicate the destination branch for a
commit. Ignore this tag.

Also ignore the gerrit 'Commit-Ready:' tag.

Signed-off-by: Simon Glass <sjg@chromium.org>

Colored logs confuse patman when analyzing logs.
Add --no-color option in git log commands in case
the default config has color.

Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@ti.com>

Sometimes we don't get a valid filename or line number from checkpatch.pl,
for example if the patch is in a bad format. Deal with this by using a
default value, rather than a stack trace.

Signed-off-by: Simon Glass <sjg@chromium.org>

Sometimes it is possible to forget the name of the branch you used to
generate an upstream series. To assist with this, add an optional
patman does not use this.

Signed-off-by: Simon Glass <sjg@chromium.org>

Specially when many revisions are need for a patchset, the most
interesting information is about the last set of changes so we output
the changelog in reverse order to easy identification of most recent
change set.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Acked-by: Simon Glass <sjg@chromium.org>

In case an address is listed in the To list, those will be skipped on
Cc list or user might end with a duplicated message.

This fixes the case when a tag points to same address used as series
destination thus avoiding duplicated sending.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>

When a patchset had a RFC series, a v1 might have a changelog of
changes done since the RFC. The patch changes the range checked for
changelog and allow it to start for version 1.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Acked-by: Simon Glass <sjg@chromium.org>

Currently patman assumes that there should be only one Signoff line
and this is obviously incorrect: we often have to work with patches
containing other people signoffs. Moreover, it's really desirable
to preserve the comments between signoffs.

So until some sophisticated signoff processing will be developed I
suggest just don't mess with signoffs at all and treat them like
plain text lines. The only drawback I've found so far is the case
where you have a patch with someones else signoff but not yours and
also have to patman tags under signoff line. In this case you will
get extra empty line between signoffs.

Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>