Alternatively we can provide an argument to control what to do in this case but I am not sure what is best. Thoughts?

Alternatively we can provide an argument to control what to do in this case but I am not sure what is best. Thoughts?

Alternatively we can provide an argument to control what to do in this case but I am not sure what is best. Thoughts?

In this case, traditionally the second option would just replace the first.

In this case, traditionally the second option would just replace the first.

In this case, traditionally the second option would just replace the first.

Replying to [comment:2 sgallagh]:

In this case, traditionally the second option would just replace the first.

But for the dry run case I think there should be a way to detect it as an error.

So I see following options:

- Overwrite (default)
- Return error 
- Ignore duplicates and get only the first

Makes sense?

And it seems that the same options should be used in the merge call.

Replying to [comment:2 sgallagh]:

In this case, traditionally the second option would just replace the first.

But for the dry run case I think there should be a way to detect it as an error.

So I see following options:

- Overwrite (default)
- Return error 
- Ignore duplicates and get only the first

Makes sense?

And it seems that the same options should be used in the merge call.

Replying to [comment:2 sgallagh]:

In this case, traditionally the second option would just replace the first.

But for the dry run case I think there should be a way to detect it as an error.

So I see following options:

- Overwrite (default)
- Return error 
- Ignore duplicates and get only the first

Makes sense?

And it seems that the same options should be used in the merge call.

Fields changed

milestone: NEEDS_TRIAGE => Tools 1.0

Fields changed

milestone: NEEDS_TRIAGE => Tools 1.0

Fields changed

milestone: NEEDS_TRIAGE => Tools 1.0

Fields changed

rhbz: => 0

Fields changed

rhbz: => 0

Fields changed

rhbz: => 0

This is not handled by merge and search code. One can force this situation to produce an error, just overwrite, just preserve first one or allow duplicates and then fetch them one by one.

blockedby: =>
blocking: =>
coverity: =>
feature_milestone: =>
milestone: Tools Backlog => Tools 1.0
patch: => 0

This is not handled by merge and search code. One can force this situation to produce an error, just overwrite, just preserve first one or allow duplicates and then fetch them one by one.

blockedby: =>
blocking: =>
coverity: =>
feature_milestone: =>
milestone: Tools Backlog => Tools 1.0
patch: => 0

This is not handled by merge and search code. One can force this situation to produce an error, just overwrite, just preserve first one or allow duplicates and then fetch them one by one.

blockedby: =>
blocking: =>
coverity: =>
feature_milestone: =>
milestone: Tools Backlog => Tools 1.0
patch: => 0

Patches have been pushed.

design: =>
design_review: => 0
fedora_test_page: =>
resolution: => fixed
status: new => closed

Patches have been pushed.

design: =>
design_review: => 0
fedora_test_page: =>
resolution: => fixed
status: new => closed

Patches have been pushed.

design: =>
design_review: => 0
fedora_test_page: =>
resolution: => fixed
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1636

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.