<div dir="ltr">On 5 December 2013 11:33, Carl Worth <span dir="ltr"><<a href="mailto:cworth@cworth.org" target="_blank">cworth@cworth.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">Carl Worth <<a href="mailto:cworth@cworth.org">cworth@cworth.org</a>> writes:<br>
> So, you should all expect to see these hook messages now:<br>
><br>
>>      remote: I: patch #<PATCHWORK_ID> updated using rev <GIT_COMMIT>.<br>
> ...<br>
>>      remote: E: failed to find patch for rev <GIT_COMMIT>.<br>
<br>
</div>For anyone who has pushed patches for the past couple of days, you<br>
likely only saw the "failed to find patch" messages.<br>
<br>
This was due to an error in my git hook, (I was trying to invoke a<br>
patchwork option that exists only in versions of patchwork newer than<br>
what we have installed on our server).<br>
<br>
Anyway, I believe I have that problem fixed now. So perhaps the<br>
git->patchwork hook will actually work going forward.<br>
<br>
I did just manually process the recent patches through the hook and an<br>
additional 260 patches were moved to the Accepted state.<br>
<br>
Have fun out there.<br>
<span class=""><font color="#888888"><br>
-Carl</font></span></blockquote><div><br></div><div>I just pushed some patches to piglit and mesa, and the script seems to be working well now.  Thanks for all your hard work on this, Carl!<br><br></div><div>BTW, I noticed a minor bug in patchwork's git commit hook this morning.  It contains this line:<br>
<br>  for rev in $(git rev-list --no-merges --reverse ${1}^..${2}); do<br><br></div><div>That "^" is superfluous, and it results in Patchwork trying to update one more patch than necessary.  For example, when I just pushed commit b9fea57f5e9501997c3d3d3789c4fff32baae7b1 (an isolated commit) to Piglit, I got this output from the commit hook:<br>
<br>remote: Updating patchwork state for <a href="http://patchwork.freedesktop.org/project/piglit/list/">http://patchwork.freedesktop.org/project/piglit/list/</a><br>remote: I: patch #16244 updated using rev 1d6ecca7760c08daadae785a3a3de5a008453dd2.<br>
remote: I: patch #16022 updated using rev b9fea57f5e9501997c3d3d3789c4fff32baae7b1.<br>remote: I: 2 patch(es) updated to state Accepted.<br><br></div><div>The update to patch 1d6ecca was totally unnecessary (and confusing), since that was the commit representing the state of the repository before I pushed.<br>
<br>Anyway, it's a benign bug, since it just results in patches getting redundantly put in the "accepted" state.  But if you feel like fixing it, Carl, it would probably avoid future confusion :)<br><br></div>
<div>Paul<br><br></div><div>P.S. I'm currently working on a script to identify patches that were recently pushed in a slightly different form than the version that was sent to the mailing list for review (e.g. in case there were merge conflicts, or minor corrections made as a result of patch review).  By default patchwork won't put these patches in the "accepted" state without manual intervention.  My script makes that manual intervention easy to do.  Once my script is sufficiently hashed out to be useful to others, I'll send out a pointer to it so that others can use it.<br>
</div></div></div></div>