On 12/31/20 11:47 AM, Matt Turner wrote:
> Since the KEYWORDS=... assignment is a single line, git struggles to
> handle conflicts. When rebasing a series of commits that modify the
> KEYWORDS=... it's usually easier to throw them away and reapply on the
> new tree than it is to manually handle con
On Mon, Dec 28, 2020 at 8:09 PM Zac Medico wrote:
>
> On 12/28/20 3:15 PM, Matt Turner wrote:
> > +def apply_keyword_changes(ebuild: str, pathname: str,
> > + changes: List[Tuple[Optional[str],
> > + Optional[str]]]) -> int:
> >
Since the KEYWORDS=... assignment is a single line, git struggles to
handle conflicts. When rebasing a series of commits that modify the
KEYWORDS=... it's usually easier to throw them away and reapply on the
new tree than it is to manually handle conflicts during the rebase.
git allows a 'merge dr
On 12/28/20 5:09 PM, Zac Medico wrote:
> On 12/28/20 3:15 PM, Matt Turner wrote:
>> +def apply_keyword_changes(ebuild: str, pathname: str,
>> + changes: List[Tuple[Optional[str],
>> + Optional[str]]]) -> int:
>> +result: int
On 12/28/20 3:15 PM, Matt Turner wrote:
> +def apply_keyword_changes(ebuild: str, pathname: str,
> + changes: List[Tuple[Optional[str],
> + Optional[str]]]) -> int:
> +result: int = 0
> +
> +# ekeyword will only modify fi
Since the KEYWORDS=... assignment is a single line, git struggles to
handle conflicts. When rebasing a series of commits that modify the
KEYWORDS=... it's usually easier to throw them away and reapply on the
new tree than it is to manually handle conflicts during the rebase.
git allows a 'merge dr