From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Thu, 28 Jan 2016 07:49:40 +0100 Subject: [U-Boot] Include patchwork patch ID in commit message? In-Reply-To: References: <20160127222209.GS426@bill-the-cat> <20160127234521.GW426@bill-the-cat> <20160128013002.GY426@bill-the-cat> Message-ID: <56A9BA04.2080101@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Bin, Am 28.01.2016 um 02:49 schrieb Bin Meng: > On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini wrote: >> On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote: >>> On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini wrote: >>>> On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote: >>>>> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini wrote: >>>>>> On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote: >>>>>>> Hi Tom, >>>>>>> >>>>>>> I'm playing with the idea of including the patchwork patch ID in the >>>>>>> commit message of each commit that I apply to provide better >>>>>>> cross-reference ability. >>>>>>> >>>>>>> * Access to comments on patches >>>>>>> * Clarity on exactly which version of a patch was applied >>>>>>> * No need to search by patch subject >>>>>>> >>>>>>> Here is an example in a working branch: >>>>>>> >>>>>>> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a >>>>>> >>>>>> I'd prfer Patchwork or Patchwork-ID or something not just Patch. >>>>> >>>>> Would it be more or less compelling if it had a format similar this? >>>>> >>>>> Patchwork: https://patchwork.ozlabs.org/patch/571773/ >>>> >>>> Yes. >>> >>> Are you being funny (more and less == not)? Or did you miss-read? :) >> >> Oops, yes, misread, yes, I like that. >> >>>>>>> What do you (or anyone else) think? >>>>>> >>>>>> Well, I'm not a super fan of it. For your second point, this is why I >>>>>> use bundles, mutt and a macro. For the other points, at least I find >>>>>> google does a good job pulling up the right patch at least. >>>>> >>>>> Bundles seem awkward. Perhaps I'm just not using them effectively. >>>>> What benefit do they give you? How are they part of your workflow? >>>> >>>> OK, I'm going to delete this in a few days but here's my bundle for the >>> >>> Doesn't that mean it will very soon not be traceable exactly which >>> patch version was applied? What I was proposing would mean that the >>> commit message could continue to refer back to the patch even if >>> archived. >> >> It means the the link I gave for the bundle will be gone. The patches >> will be there, but I will also move them from Under Review to Accepted. >> >>>> last import I did: >>>> https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/ >>>> My flow is: >>>> 1) Assign all unassigned patches >>>> 2) Open my todo list in patchwork >>>> 3) Create a bundle with all of the patches I want based on my critera at >>>> the time. >>>> 4) Download bundle as mbox, git am -3 it, get big build going. >>>> 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed >>>> at first >>>> 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for >>>> each email group reply, run macro to insert applied message, postponed >>>> 7) Check output from big build, assuming good results, push and spam out >>>> all of my queued messages. >>> >>> Gotcha. Thanks! >>> >>> I'm trying to improve my workflow now, and this Patch tag was >>> something that came out of it. It's not required for the workflow, but >>> it is free to do within it. It has the potential to slightly simplify >>> one possible workflow, so no big deal. >>> >>> If people think it will be simply noise, I'll leave it out. >>> >>> I think this may speed up cross-referencing. Seemed like a good thing. >> >> My concern is that since it's not injected by patchwork already I would >> have to add it to each commit. Today, unless I need to either make >> something apply or do a minor fixup to the contents, I don't modify any >> commit message, so my git am is it. > > Does it make sense to enhance patchwork to inject such link into the > commit automatically? It can also be a project configuration option so > that other projects tracked by patchwork can turn it on on their > needs. +1 bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany