Hello Bin,
Am 28.01.2016 um 02:49 schrieb Bin Meng:
On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini <tr...@konsulko.com> 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 <tr...@konsulko.com> 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 <tr...@konsulko.com> 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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
