From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerlando Falauto Date: Wed, 04 Apr 2012 18:38:16 +0200 Subject: [U-Boot] [PATCH v4] Add 'patman' patch generation, checking and submission script In-Reply-To: References: <1326589965-4271-1-git-send-email-sjg@chromium.org><4F7C2403.5040500@keymile.com> Message-ID: <4F7C78F8.8060304@keymile.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/04/2012 06:16 PM, Simon Glass wrote: > Hi Gerlando, > > On Wed, Apr 4, 2012 at 3:35 AM, Gerlando Falauto > wrote: >> Hi Simon, >> >> OK I haven't tried it yet, but this sounds awesome. >> I wonder how people manage to send and rework their patches without such >> tool. Even one single patchset has been giving me strong enough headaches so >> far, not to mention the massive waste of time. > > Yes I wrote it when I had to do a few revisions of a relatively small > series. It was very difficult and time-consuming to get everything > right for submission. Now it is mostly automatic. > >> >> I pretty much agree with Albert, this should eventually move out of u-boot. >> But you need to start somewhere, and this is perhaps a good testbed to get >> people to use it. I believe it should perhaps eventually be integrated into >> git as it makes for a wonderful enhancement (or wrapper) over git >> format-patch and git send-email. > > Yes, the only thing that would need to be sorted out is the hooks for > checkpatch. Wouldn't something in ~/.gitconfig do the trick? >> As I said I haven't tested it yet, but I would like to contribute a couple >> questions / suggestions for enhancements out of your README: >> >> 1) Marking the test setup commits using tags as well. Something like >> >> Series-exclude: true >> >> I mean, I tend to forget (and make mistakes) pretty easily. Not having to >> remember that a given commit is for testing only makes it more difficult for >> me to go wrong. Even that extra "-s1" I could easily miss... Also, it >> *might* be also useful to have those test commits somewhere in the middle of >> the patch series, perhaps. > > Yes I think that is useful, and it fits with the idea of not needed > any args in the normal case. I will stick it on the list. > >> >> 2) Do you think it would be possible to write the cover letter on a commit >> of its own? I believe git doesn't allow you to create a commit not touching >> any file, but perhaps one might find some way arount it as well. > > You can put it in any commit, and in principle in its own commit, but > 'git rebase -i' doesn't like empty commits in my experience. > >> Maybe the cover letter itself could be written as an added file to such >> commit, and then tagged with something like: >> >> Cover-letter-file: wonderfulpatchset.txt >> >> This might turn out useful, as one could easily edit the file while >> reworking the patchset from the top commit, and then attribute it to such >> commit, wherever it is located in the tree. >> >> What do you think? > > Easy to do - I wonder if it might be better to commit that file to a > separate commit (which is marked Series-exclude:). Otherwise you have > a dangling file that might hang around for weeks and is very > vulnerable to accidents. You mean not committing the cover letter file being the alternative? I believe you definitely *don't* want files hanging (not under revision control) anywhere, at any time. At least, _I don't_. So the cover letter commit could contain all the needed information, (like recipients, revision etc) including a file with the text of the cover letter. Having it marked as Series-exclude (or whatever) would just not count it as a patch file to send out. Not quite sure whether it's trivial to deal with the numbering though. >> Thanks again for the tool! > > Thanks for looking at it. We will see if this goes into U-Boot this time. Thanks, Gerlando > > Regards, > Simon > >> >> Gerlando >> >> >> On 01/15/2012 02:12 AM, Simon Glass wrote: >>> 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: >>> >> [...]