[
https://issues.apache.org/jira/browse/YETUS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16556153#comment-16556153
]
Allen Wittenauer edited comment on YETUS-645 at 7/25/18 7:21 PM:
-----------------------------------------------------------------
In general, if Yetus can't apply the patch, it will complain loudly. See
https://issues.apache.org/jira/browse/HADOOP-12953?focusedCommentId=15207216&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15207216
as an example.
However, IIRC, there is at least one edge case where patches can go haywire:
the patch only creates a new subdirectory with no other point of reference.
e.g., +++ newdir/foo . There's a bit of work in place to make sure it has the
correct location to apply a patch, but with no markers... it's a bit of a
crapshoot.
That said, I think something else is going wrong in the examples provided.
LUCENE-8369 almost certainly applied. I just manually added it to the build
queue to see what is going on there. (The logs have scrolled off...) My hunch
on LUCENE-8408 is that it probably got caught up in the several rounds of
Jenkins downtime that happened last weekend and into early last week.
Also:
bq. Yetus probably didn't have enough time to process the first patch
Yetus will make a note as to which patch it tried to process. One can look at
that 'JIRA Patch URL' field in the bottom of the report to see which one was
being used. In the case of SOLR-12561, the actual URL provides the hints: the
patch at attachment id 12932109 got processed twice. Thus confirming your
suspicion. [I totally admit I play the "can I beat Jenkins?" game too. :) ]
That said this is exactly why it is highly recommended to revision patch
uploads. This makes it easier to see which report applies to which patches at a
glance. e.g., YETUS-441 provides a great example.
was (Author: aw):
In general, if Yetus can't apply the patch, it will complain loudly. See
https://issues.apache.org/jira/browse/HADOOP-12953?focusedCommentId=15207216&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15207216
as an example.
However, IIRC, there is at least one edge case where patches can go haywire:
the patch only creates a new subdirectory with no other point of reference.
e.g., +++ newdir/foo . There's a bit of work in place to make sure it has the
correct location to apply a patch, but with no markers... it's a bit of a
crapshoot.
That said, I think something else is going wrong in the examples provided.
LUCENE-8369 almost certainly applied. I just manually added it to the build
queue to see what is going on there. (The logs have scrolled off...) My hunch
on LUCENE-8408 is that it probably got caught up in the several rounds of
Jenkins downtime that happened last weekend and into early last week.
Also:
> Yetus probably didn't have enough time to process the first patch
IYetus will make a note as to which patch it tried to process. One can look at
that 'JIRA Patch URL' field in the bottom of the report to see which one was
being used. In the case of SOLR-12561, the actual URL provides the hints: the
patch at attachment id 12932109 got processed twice. Thus confirming your
suspicion. [I totally admit I play the "can I beat Jenkins?" game too. :) ]
That said this is exactly why it is highly recommended to revision patch
uploads. This makes it easier to see which report applies to which patches at a
glance. e.g., YETUS-441 provides a great example.
> Make leading path component optional in patch files (support IntelliJ patch
> files)
> ----------------------------------------------------------------------------------
>
> Key: YETUS-645
> URL: https://issues.apache.org/jira/browse/YETUS-645
> Project: Yetus
> Issue Type: Improvement
> Reporter: David Smiley
> Priority: Major
>
> IntelliJ IDEA has a "create patch" feature that generates patch files in a
> format that isn't supported by some tools like Yetus. In particular, there
> is no leading "a/" and "b/" in the paths. That appears to be the sole
> difference requiring these patches to be supported.
>
> See [https://youtrack.jetbrains.com/issue/IDEA-92793]
>
> To work around this, I wrote a one-liner Bash script using SED to insert the
> "a/" and b/" at the right spots:
> {code:java}
> sed -i '' -e 's/^--- /--- a\//g' -e 's/^+++ /+++ b\//g' "$1"
> {code}
> In this issue I propose that Yetus detect the absence of a/ and b/ and either
> (a) insert them using a similar script, or (b) toggling the "-p" option when
> the patch is applied using [git-apply|https://git-scm.com/docs/git-apply] or
> other tool.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
