1. 15 Oct, 2019 1 commit
    • Douglas Anderson's avatar
      patman: Use the Change-Id, version, and prefix in the Message-Id · 833e4192
      Douglas Anderson authored
      As per the centithread on ksummit-discuss [1], there are folks who
      feel that if a Change-Id is present in a developer's local commit that
      said Change-Id could be interesting to include in upstream posts.
      Specifically if two commits are posted with the same Change-Id there's
      a reasonable chance that they are either the same commit or a newer
      version of the same commit.  Specifically this is because that's how
      gerrit has trained people to work.
      There is much angst about Change-Id in upstream Linux, but one thing
      that seems safe and non-controversial is to include the Change-Id as
      part of the string of crud that makes up a Message-Id.
      Let's give that a try.
      In theory (if there is enough adoption) this could help a tool more
      reliably find various versions of a commit.  This actually might work
      pretty well for U-Boot where (I believe) quite a number of developers
      use patman, so there could be critical mass (assuming that enough of
      these people also use a git hook that adds Change-Id to their
      commits).  I was able to find this git hook by searching for "gerrit
      change id git hook" in my favorite search engine.
      In theory one could imagine something like this could be integrated
      into other tools, possibly even git-send-email.  Getting it into
      patman seems like a sane first step, though.
      NOTE: this patch is being posted using a patman containing this patch,
      so you should be able to see the Message-Id of this patch and see that
      it contains my local Change-Id, which ends in 2b9 if you want to
      [1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-August/006739.htmlSigned-off-by: default avatarDouglas Anderson <dianders@chromium.org>
  2. 23 Jun, 2018 1 commit
  3. 07 May, 2018 1 commit
    • Tom Rini's avatar
      SPDX: Convert all of our single license tags to Linux Kernel style · 83d290c5
      Tom Rini authored
      When U-Boot started using SPDX tags we were among the early adopters and
      there weren't a lot of other examples to borrow from.  So we picked the
      area of the file that usually had a full license text and replaced it
      with an appropriate SPDX-License-Identifier: entry.  Since then, the
      Linux Kernel has adopted SPDX tags and they place it as the very first
      line in a file (except where shebangs are used, then it's second line)
      and with slightly different comment styles than us.
      In part due to community overlap, in part due to better tag visibility
      and in part for other minor reasons, switch over to that style.
      This commit changes all instances where we have a single declared
      license in the tag as both the before and after are identical in tag
      contents.  There's also a few places where I found we did not have a tag
      and have introduced one.
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
  4. 12 Sep, 2017 1 commit
  5. 06 Feb, 2016 1 commit
  6. 28 Jul, 2015 1 commit
  7. 23 Apr, 2015 1 commit
  8. 30 Jan, 2015 1 commit
  9. 21 Sep, 2014 1 commit
  10. 09 May, 2014 1 commit
  11. 22 Mar, 2014 1 commit
    • Simon Glass's avatar
      patman: Use Patch-cc: instead of Cc: · 659c89da
      Simon Glass authored
      Add a new Patch-cc: tag which performs the service now provided by
      the Cc: tag. The Cc: tag is interpreted by git send-email but
      ignored by patman.
      So now:
        Cc: patman does nothing. (git send-email can cc patches)
        Patch-cc: patman Cc's patch and removes this tag from the patch
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
  12. 21 Nov, 2013 1 commit
  13. 24 Jul, 2013 1 commit
  14. 15 Jul, 2013 1 commit
  15. 08 Apr, 2013 1 commit
  16. 04 Apr, 2013 3 commits
  17. 31 Jan, 2013 4 commits
    • Doug Anderson's avatar
      patman: Add the concept of multiple projects · a1dcee84
      Doug Anderson authored
      There are cases that we want to support different settings (or maybe
      even different aliases) for different projects.  Add support for this
      * 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
      Signed-off-by: default avatarDoug Anderson <dianders@chromium.org>
      Acked-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
    • Doug Anderson's avatar
      patman: Add support for settings in .patman · 8568baed
      Doug Anderson authored
      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:
       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: default avatarDoug Anderson <dianders@chromium.org>
    • Doug Anderson's avatar
      patman: Add a call to get_maintainer.pl if it exists · 21a19d70
      Doug Anderson authored
      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: default avatarDoug Anderson <dianders@chromium.org>
    • Doug Anderson's avatar
      patman: Add all CC addresses to the cover letter · 31187255
      Doug Anderson authored
      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: default avatarDoug Anderson <dianders@chromium.org>
  18. 15 Oct, 2012 1 commit
  19. 19 Jun, 2012 2 commits
  20. 30 Apr, 2012 2 commits
  21. 21 Apr, 2012 2 commits
    • Wolfgang Denk's avatar
      Prepare v2012.04 · 2790bf69
      Wolfgang Denk authored
      Also tiny style cleanup to tools/patman/README
      Signed-off-by: Wolfgang Denk's avatarWolfgang Denk <wd@denx.de>
    • Simon Glass's avatar
      Add 'patman' patch generation, checking and submission script · 0d24de9d
      Simon Glass authored
      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.
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>