Suricata

Hello, I want to work on this.

But then, I'll be working on the same file (detect-engine-analyzer.c) I worked with on my last contribution, which has been approved but not merged yet. How do I handle it so there is no merge conflict when this is to be merged? Should I just add the previous edits I made before on this one too, by myself?

Daniel Olatunji wrote in #note-3:

Hello, I want to work on this.

Ok, please, assign it to yourself, and thanks!

But then, I'll be working on the same file (detect-engine-analyzer.c) I worked with on my last contribution, which has been approved but not merged yet. How do I handle it so there is no merge conflict when this is to be merged? Should I just add the previous edits I made before on this one too, by myself?

Imho, the correct procedure here would be to create your new branch from master, and if the other PR gets merged before this new contribution, you would rebase your new work, and fix any existing conflicts.

(But you could also create your branch on top of the changes you've done, and then once those got merged and you rebased, they'd be skipped.)

Does that answer your question?

Juliana Fajardini Reichow wrote in #note-4:

Daniel Olatunji wrote in #note-3:

Hello, I want to work on this.

Ok, please, assign it to yourself, and thanks!

But then, I'll be working on the same file (detect-engine-analyzer.c) I worked with on my last contribution, which has been approved but not merged yet. How do I handle it so there is no merge conflict when this is to be merged? Should I just add the previous edits I made before on this one too, by myself?

Imho, the correct procedure here would be to create your new branch from master, and if the other PR gets merged before this new contribution, you would rebase your new work, and fix any existing conflicts.

(But you could also create your branch on top of the changes you've done, and then once those got merged and you rebased, they'd be skipped.)

Does that answer your question?

What if I had already submitted a new PR before the previous one was merged?

Daniel Olatunji wrote in #note-5:

Juliana Fajardini Reichow wrote in #note-4:

Daniel Olatunji wrote in #note-3:

Hello, I want to work on this.

Ok, please, assign it to yourself, and thanks!

But then, I'll be working on the same file (detect-engine-analyzer.c) I worked with on my last contribution, which has been approved but not merged yet. How do I handle it so there is no merge conflict when this is to be merged? Should I just add the previous edits I made before on this one too, by myself?

Imho, the correct procedure here would be to create your new branch from master, and if the other PR gets merged before this new contribution, you would rebase your new work, and fix any existing conflicts.

(But you could also create your branch on top of the changes you've done, and then once those got merged and you rebased, they'd be skipped.)

Does that answer your question?

What if I had already submitted a new PR before the previous one was merged?

If you follow the first approach, there's nothing to be done, as this is a different keyword.

If you follow the second approach, you could mention on the new PR that you have built your work on top of previous work done on PR #6415
But considering this, I would say that it is indeed preferable that you take the first approach, therefore you don't have to link unrelated work in your new PR. It is not uncommon to have situations like this, and in such cases we will rebase and handle any possible merge conflicts that may occur - but I would expect this work not to lead to complex merge conflicts, as although it is the same file, you'll be adding a different keyword case.

Juliana Fajardini Reichow wrote in #note-7:

Daniel Olatunji wrote in #note-5:

Juliana Fajardini Reichow wrote in #note-4:

Daniel Olatunji wrote in #note-3:

Hello, I want to work on this.

Ok, please, assign it to yourself, and thanks!

But then, I'll be working on the same file (detect-engine-analyzer.c) I worked with on my last contribution, which has been approved but not merged yet. How do I handle it so there is no merge conflict when this is to be merged? Should I just add the previous edits I made before on this one too, by myself?

Imho, the correct procedure here would be to create your new branch from master, and if the other PR gets merged before this new contribution, you would rebase your new work, and fix any existing conflicts.

(But you could also create your branch on top of the changes you've done, and then once those got merged and you rebased, they'd be skipped.)

Does that answer your question?

What if I had already submitted a new PR before the previous one was merged?

If you follow the first approach, there's nothing to be done, as this is a different keyword.

If you follow the second approach, you could mention on the new PR that you have built your work on top of previous work done on PR #6415
But considering this, I would say that it is indeed preferable that you take the first approach, therefore you don't have to link unrelated work in your new PR. It is not uncommon to have situations like this, and in such cases we will rebase and handle any possible merge conflicts that may occur - but I would expect this work not to lead to complex merge conflicts, as although it is the same file, you'll be adding a different keyword case.

OK then.

I understand now.
Thank you for your constant assistance :).

I had been going down a never ending rabbit hole on this one, and it gets more confusing for me, since I am not very proficient in C.
I have been on it for a couple of days now, and cannot seem to figure out how to work with the "DetectU16Data".

I have looked through the file "detect-engine-uint.c" and it's corresponding header file.