Indeed, GitHub forbids you from attaching a file with extension .patch! Sort of annoying :)
But then one workaround is to rename it to XXXX-patch.txt or so. Of course, GitHub won't do pretty rendering of the .patch syntax, but then I don't think Jira does either? It's just an attachment that you must download and apply to your local git clone. GitHub does support mapping a PR to a patch or diff file -- you just download the full path to the PR, but add .diff or .patch extension. E.g. https://github.com/apache/lucene-jira-archive/pull/49.patch or https://github.com/apache/lucene-jira-archive/pull/49.diff. The .diff is a straight diff (like "git diff") of all the cumulative changes/commits in the PR, while the .patch shows a concatenation of the individual commits. Mike McCandless http://blog.mikemccandless.com On Mon, Jul 18, 2022 at 12:41 AM Tomoko Uchida <tomoko.uchida.1...@gmail.com> wrote: > I agree that "discussion" will be done on mailing lists (as always). > Properly speaking, stopping using Jira means "we don't accept patch style > contributions anymore". > GitHub doesn't allow ".patch" files as attachments; it'd be reasonable for > GitHub. > > https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/attaching-files > > I'm not sure if it has a substantial effect and I myself am fine with that > - just wanted to clarify what we are going to discard. > > Tomoko > > > 2022年7月17日(日) 23:40 Michael Sokolov <msoko...@gmail.com>: > >> I think we'd still have the mailing lists open for discussion. So anyone >> not willing or able to use GitHub would still be able to participate in a >> meaningful way. Having two parallel bug trackers seems much less useful to >> me. I'd rather have people emailing to a list that is active rather than >> posting comments to a repository that we may very likely start to ignore. >> >> On Sun, Jul 17, 2022, 10:09 AM Tomoko Uchida < >> tomoko.uchida.1...@gmail.com> wrote: >> >>> Thank you Mike for opening the discussion. >>> >>> I don't really have a clear "opinion" on that, but I just wanted to try >>> to explain my perspective. >>> >>> Today almost all development is already going on GitHub pull requests, >>> then it would be a natural direction for the majority of devs to move our >>> primary conversation platform to GitHub. I think we should try to optimize >>> our environment for majorities, although I know we will never be able to >>> reach a unanimous agreement. >>> Meanwhile, it was not my intention to completely discontinue the >>> contribution path via Jira. I rather optimistically thought we could leave >>> room for developers who don't use GitHub for any reason. >>> >>> As for preventing someone from "accidentally" opening Jira issues, we >>> could show a text that says "Jira has been deprecated. Please open GitHub >>> issue unless you are not able to do so." when he/she is attempting to open >>> Jira. >>> >>> https://confluence.atlassian.com/adminjiraserver/configuring-contexts-and-default-values-for-the-description-field-1047552727.html >>> >>> I agree that it'd be the cleanest way to make Jira read-only and I >>> myself am fine with the proposal - maybe I'm overthinking. >>> >>> Tomoko >>> >>> >>> 2022年7月17日(日) 22:13 Michael McCandless <luc...@mikemccandless.com>: >>> >>>> Hi Team, >>>> >>>> Thanks to Tomoko's amazing hard work ( >>>> https://github.com/apache/lucene-jira-archive), we are getting close >>>> to having strong tooling and a solid plan to migrate all past Jira issues >>>> to GItHub issues! >>>> >>>> But one contentious point is whether to leave Jira read-only or >>>> read-write after the migration. So let's DISCUSS and maybe VOTE to reach >>>> concensus? >>>> >>>> My opinion: I think it'd be crazy to leave Jira read/write. We would >>>> effectively have two issue trackers. New users who find Jira through >>>> Google, or through links we have in old blog posts, etc., might >>>> accidentally open new Jira issues or comment on old ones and we may not >>>> even notice. I think that would harm our community. >>>> >>>> I would prefer that we make a nearly atomic switch -- up until time X >>>> we use Jira, then it goes read-only and at time X + t (t being how long the >>>> migration takes, likely a day or two?), GitHub issues opens for business. >>>> This way we clarly have only one issue tracker at (nearly) all times. This >>>> would make a clean migration, and reduce risk of trapping users. >>>> >>>> Other opinions? >>>> >>>> Thanks, >>>> >>>> Mike >>>> -- >>>> Mike McCandless >>>> >>>> http://blog.mikemccandless.com >>>> >>>
