[U-Boot] [PATCH v4] Add 'patman' patch generation, checking and submission script

[Simon Glass]

Hi Gerlando,

On Wed, Apr 4, 2012 at 9:38 AM, Gerlando Falauto
<gerlando.falauto at 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.falauto at 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:
>>>>
>>> [...]
>
>