public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Gerlando Falauto <gerlando.falauto@keymile.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4] Add 'patman' patch generation, checking and submission script
Date: Wed, 04 Apr 2012 18:38:16 +0200	[thread overview]
Message-ID: <4F7C78F8.8060304@keymile.com> (raw)
In-Reply-To: <CAPnjgZ20QcG+tnNL45QSfVLqxJMB1HMUVbb4LjymTWgbaWBFDA@mail.gmail.com>

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@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?

>> 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:
>>>
>> [...]

  reply	other threads:[~2012-04-04 16:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-15  1:12 [U-Boot] [PATCH v4] Add 'patman' patch generation, checking and submission script Simon Glass
2012-01-15  1:20 ` Simon Glass
2012-02-03 19:00   ` Albert ARIBAUD
2012-02-03 19:30     ` Simon Glass
2012-02-03 20:00       ` Albert ARIBAUD
2012-02-05  5:46         ` Simon Glass
2012-02-12 13:55           ` Albert ARIBAUD
2012-04-04 10:35 ` Gerlando Falauto
2012-04-04 16:16   ` Simon Glass
2012-04-04 16:38     ` Gerlando Falauto [this message]
2012-04-04 16:43       ` Simon Glass
2012-04-21 15:26 ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F7C78F8.8060304@keymile.com \
    --to=gerlando.falauto@keymile.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox