yetus-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allen Wittenauer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YETUS-645) Make leading path component optional in patch files (support IntelliJ patch files)
Date Wed, 25 Jul 2018 19:20:00 GMT

    [ https://issues.apache.org/jira/browse/YETUS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16556153#comment-16556153
] 

Allen Wittenauer commented on YETUS-645:
----------------------------------------

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)

Mime
View raw message