Implement the `~` merge operation

[lukaszachy]

WDYT?

Todo:

• [x] find BETTER_NAME for this helper function
• [x] Documentation
• [x] smuggle '-~' operator (delete if matches regexp)

[lukaszachy]

~ should be done now

I'll add tests and docs for -~ tomorrow.

[thrix]

@LecrisUT can you resolve comments which you are happy about pls?

[LecrisUT]

@LecrisUT can you resolve comments which you are happy about pls?

Issue is that I can't. I can only resolve comments on PRs that I have opened.

I'll give it one more look again tomorrow, but I think all of the issues are resolved. I think the only part is about "\\1", which might be better replaced with '\1' to be inline with the comment:

In the fmf file it is better to use single quotes ``'`` as they do not need such intensive escaping::

(actually maybe should still keep at least one case with "\\1" to be extra safe)

[lukaszachy]

Issue is that I can't. I can only resolve comments on PRs that I have opened.

Yeah. This limitation from github is really strange:/ I have no idea that why anyone who can comment is not suddenly allowed to resolve conversation they started.

[lukaszachy]

/examples/merge/parent.fmf now uses also single quotes so the \1 doesn't need to be escaped

[martinhoyer]

I like the functionality, but this might be too much regex magic from my PoV. It might get messy with the escapes, etc.
That said, I'm sure you all regex wizards know what you're doing :) Fwiw though, I'd be willing to rewrite it without usage of re module.

[LecrisUT]

I like the functionality, but this might be too much regex magic from my PoV. It might get messy with the escapes, etc.

That was an initial concern for me as well, but check the implementation of fmf.utils.split_pattern_repl. There there is no escaping (other than that coming from yaml, but that's why there is is the documentation suggestion of using ' to reduce escaping).

Fwiw though, I'd be willing to rewrite it without usage of re module

Problem would be with regex groups (named/unnamed). I think that's an important feature to support for this.

[martinhoyer]

Problem would be with regex groups (named/unnamed). I think that's an important feature to support for this.

@LecrisUT No idea what what those are. Any chance you could enlighten me by pointing to how are they being used here, pretty please?

[LecrisUT]

Problem would be with regex groups (named/unnamed). I think that's an important feature to support for this.

@LecrisUT No idea what what those are. Any chance you could enlighten me by pointing to how are they being used here, pretty please?

An example is worth a hundred words :P. See the () in the search string and the $1 in the replace.

[martinhoyer]

Problem would be with regex groups (named/unnamed). I think that's an important feature to support for this.

@LecrisUT No idea what what those are. Any chance you could enlighten me by pointing to how are they being used here, pretty please?

An example is worth a hundred words :P. See the () in the search string and the $1 in the replace.

Thanks. I still don't get why it's needed, but guessing it is important when you want the users to be able to use regex. I was thinking more about allowing just some "simple" substitutions. :)

[psss]

Fixed a few typos and proposing some minor adjustments in 3a8ee40.

[lukaszachy]

Does someone explain how can fedora-40 and c9s fail on TypeError: adjust() got an unexpected keyword argument 'additional_rules' but rawhide and f-39 pass?

[LecrisUT]

Could be a race condition. Packit uses the merge commit and not the source commit iirc. But the srpm should be the same for all builds so not quite sure

[lukaszachy]

@thrix ? The passing job https://artifacts.dev.testing-farm.io/156d927c-3f15-47f6-8729-adcd97d0ef5f/#artifacts-/plans/features has

git -C testcode fetch https://github.com/teemtee/fmf 33c920df4b1481e14c0c707b0c5469961736a88e:gluetool/33c920df4b1481e14c0c707b0c5469961736a88e
git -C testcode checkout gluetool/33c920df4b1481e14c0c707b0c5469961736a88e
git -C testcode fetch https://github.com/teemtee/fmf 3a8ee401fbaa776f112a7d7948aa8eef935d0743:gluetool/3a8ee401fbaa776f112a7d7948aa8eef935d0743
git -C testcode merge --no-edit gluetool/3a8ee401fbaa776f112a7d7948aa8eef935d0743

but failing one https://artifacts.dev.testing-farm.io/9db4c21f-82b9-4f8d-bceb-806577dec328/#artifacts-/plans/features has

git -C testcode fetch https://github.com/teemtee/fmf 673c83ca1cb35256690677c1cddc88a4a2025586:gluetool/673c83ca1cb35256690677c1cddc88a4a2025586
git -C testcode checkout gluetool/673c83ca1cb35256690677c1cddc88a4a2025586
git -C testcode fetch https://github.com/teemtee/fmf 3a8ee401fbaa776f112a7d7948aa8eef935d0743:gluetool/3a8ee401fbaa776f112a7d7948aa8eef935d0743
git -C testcode merge --no-edit gluetool/3a8ee401fbaa776f112a7d7948aa8eef935d0743

Shouldn't be it the same?

[lukaszachy]

Could be a race condition. Packit uses the merge commit and not the source commit iirc. But the srpm should be the same for all builds so not quite sure

Ah, I guess you are right. Job ran 4h ago and merge (introducing additional_rules) happened also around that time.

[lukaszachy]

@psss I used 'repl' because re.sub(pattern, repl, string, count=0, flags=0) is used in Python itself. But OK to keep longer name.