Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Mon, 1 Mar 2021 22:54:45 -0500 Matt Turner wrote: > tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote, > called merge-driver-ekeyword that can automatically resolve git merge > conflicts involving the KEYWORDS=... line in ebuilds. > > To use the merge driver, configure your ge

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Tue, Mar 2, 2021 at 3:12 PM Michael Orlitzky wrote: > > On Tue, 2021-03-02 at 14:02 -0500, Matt Turner wrote: > > On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky wrote: > > > why don't we just enforce putting each > > > keyword on a separate line instead, so th

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Tue, Mar 2, 2021 at 2:36 PM Alessandro Barbieri wrote: > > Il Mar 2 Mar 2021, 20:03 Matt Turner ha scritto: >> >> On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky wrote: >> > why don't we just enforce putting each >> > keyword on a separate line instead, so tha

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Tue, 2021-03-02 at 15:16 -0500, Michael Orlitzky wrote: > On Tue, 2021-03-02 at 20:42 +0100, Michał Górny wrote: > > > > Are you volunteering to fix all the tools to support the new format > > correctly? > > > > When you already spend all day fixing other peoples' software, this > doesn't sou

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Tue, 2021-03-02 at 20:42 +0100, Michał Górny wrote: > > Are you volunteering to fix all the tools to support the new format > correctly? > When you already spend all day fixing other peoples' software, this doesn't sound that scary. The PMS says that KEYWORDS is whitespace-separated. Probabl

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Tue, 2021-03-02 at 14:02 -0500, Matt Turner wrote: > On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky wrote: > > why don't we just enforce putting each > > keyword on a separate line instead, so that we don't have this problem > > in the first place? > > Why don

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Tue, 2021-03-02 at 00:10 -0500, Michael Orlitzky wrote: > On Mon, 2021-03-01 at 22:54 -0500, Matt Turner wrote: > > tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote, > > called merge-driver-ekeyword that can automatically resolve git merge > > conflicts involving the KEYWORDS=..

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On 3/2/2021 2:36 PM, Alessandro Barbieri wrote: Il Mar 2 Mar 2021, 20:03 Matt Turner > ha scritto: On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky mailto:m...@gentoo.org>> wrote: >                                 why don't we just enforce putting each

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

Il Mar 2 Mar 2021, 20:03 Matt Turner ha scritto: > On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky wrote: > > why don't we just enforce putting each > > keyword on a separate line instead, so that we don't have this problem > > in the first place? > > Why don't w

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky wrote: > why don't we just enforce putting each > keyword on a separate line instead, so that we don't have this problem > in the first place? Why don't we change 30 thousand ebuilds rather than use this script?

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

On Tue, Mar 2, 2021 at 6:11 AM Wolfgang E. Sanyer wrote: > Git diff has --color-word, doesn't this suggest that it has the capability of > identifying these word-by-word changes? No, git diff has that feature. That doesn't imply that the default merge driver has that feature. > Is there perhaps

Re: [gentoo-dev] [RFC] Dropping PyPy(3) back to ~arch

On 02/03/2021 16:05, Michał Górny wrote: Hi, Hi I don't really want to remove it entirely or revert all the work we've put into testing packages with it -- but I think we should move it to ~arch at the very least. WDYT? I agree with you, I'd drop it back to ~arch too. Thanks for your w

[gentoo-dev] [RFC] Dropping PyPy(3) back to ~arch

Hi, I think I've made a mistake by stabilizing PyPy(3), and I would like to drop it back to ~arch (and stable-mask the relevant flags). Roughly, there are 4 problems with it: 1. The current stable (both Gentoo and upstream) is PyPy3.6 that is equivalent to CPython 3.6. Yes, the one we removed a

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

Git diff has --color-word, doesn't this suggest that it has the capability of identifying these word-by-word changes? Is there perhaps a merge option that is being overlooked? El mar., 2 de marzo de 2021 12:21 a. m., Sam James escribió: > > > On 2 Mar 2021, at 05:10, Michael Orlitzky wrote: >

[gentoo-dev] Package up for grabs: dev-python/python-backoff

We have and ebuild for this package up for grabs: https://pypi.org/project/backoff/ No open bugs and no reverse dependencies: https://bugs.gentoo.org/buglist.cgi?quicksearch=python-backoff -- Thanks, Zac signature.asc Description: OpenPGP digital signature