| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Don't try to sort and uniq changelog entries as this breaks
multiline entries. It will be better to add some real multi-line
support but for now just preserve the entries as is.
Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>
|
|
We already got all changes from git log output and the comment
to the ProcessLine function clearly states that 'patch' mode
is not for scanning tags.
Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>
|
|
Changes may end in '---' line or Signoff line (generated by
git format-patch) in case of Series-changes: lines being
the last ones in commit message. So detect it properly.
Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>
|
|
patman shouts when it couldn't find a $(HOME)/.patman file.
Handle it in a sane way by creating a new one for the user.
It looks for a user.name and user.email in the global .gitconfig
file, waits for the user input if it can't find there. Update the
same in the README
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Wolfgang Denk <wd@denx.de>
|
|
Move the config file from ~/.config/patman to ~/.patman as it is
more appropriate to have it there. Update the same in the README.
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Wolfgang Denk <wd@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Fix the location of patman path in README
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Also tiny style cleanup to tools/patman/README
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
What is this?
=============
This tool is a Python script which:
- Creates patch directly from your branch
- Cleans them up by removing unwanted tags
- Inserts a cover letter with change lists
- Runs the patches through checkpatch.pl and its own checks
- Optionally emails them out to selected people
It is intended to automate patch creation and make it a less
error-prone process. It is useful for U-Boot and Linux work so far,
since it uses the checkpatch.pl script.
It is configured almost entirely by tags it finds in your commits.
This means that you can work on a number of different branches at
once, and keep the settings with each branch rather than having to
git format-patch, git send-email, etc. with the correct parameters
each time. So for example if you put:
in one of your commits, the series will be sent there.
See the README file for full details.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
|
