Hi Gerlando, On Wed, Apr 4, 2012 at 9:38 AM, Gerlando Falauto <gerlando.fala...@keymile.com> wrote: > On 04/04/2012 06:16 PM, Simon Glass wrote: >> >> Hi Gerlando, >> >> On Wed, Apr 4, 2012 at 3:35 AM, Gerlando Falauto >> <gerlando.fala...@keymile.com> 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?
It would help, but checkpatch presents information in a certain way and at present patman interprets and summarises the results. So to do that we would need to add checkpatch-specific code somewhere. > > >>> 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. OK sorry I misunderstood, in that case I am fine with it, yes I thought you meant a file outside version control. You can put the tags in any commit, but tags in skipped commits are currently ignored. With your Series-exclude feature we can fix that. The numbering is easy enough, although it would be nice to avoid having excluded commits in the middle of the series. Regards, Simon > > >>> 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: >>>> >>> [...] > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot