Resolve merge conflict for #3558

[Anish9901]

In #3546 we removed a bunch of stuff related to the Debian build form our codebase of which one was pyproject.toml, during the release process however, we change the version number in the pyproject.toml file which is now producing conflict in #3558. This PR is a temporary fix to resolve the conflict to get #3558 merged, and we could revert the changes made in this PR later.

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the develop branch of the repository
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no
  visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[mathemancer]

There must be a better way, but I don't know it.

[seancolsen]

There must be a better way, but I don't know it.

Seems like @mathemancer and @Anish9901 are half way through fixing this problem, but I just wanted to chime in to say that (in the future) I think we'd be able to address problems like this by doing something the following locally:

git fetch origin
git checkout develop
git merge master      # this halts because there's a merge conflict
git rm pyproject.toml # this resolves the merge conflict
git commit            # this completes the merge
git push              # this closes the PR

Perhaps I'm not understanding the problem correctly though.

Note that with pyproject.toml gone, we'll also need to update the release cutting steps. @Anish9901 would you be up for doing that?

[Anish9901]

Note that with pyproject.toml gone, we'll also need to update the release cutting steps. @Anish9901 would you be up for doing that?

Yes, I'll do that.

I think we'd be able to address problems like this by doing something the following locally

git fetch origin
git checkout develop
git merge master      # this halts because there's a merge conflict
git rm pyproject.toml # this resolves the merge conflict
git commit            # this completes the merge
git push              # this closes the PR

git rm pyproject.toml deletes the entire file from the codebase instead of removing the changes affected by master, but you are right I could have done something like this to avoid creating this PR. Thanks for suggesting this!

[seancolsen]

git rm pyproject.toml deletes the entire file from the codebase instead of removing the changes affected by master

From what I can tell, we had one change which deleted a file and another change which modified that same file. In the context of resolving a merge conflict between those two kinds of changes git rm will tell git to accept the change that deleted the file (which is what I think we want here). It will stage that file deletion to be committed (with the merge), even if the file doesn't exist in your working copy. In this context git rm behaves a little differently than how it usually behaves. Anyway, just a tip!

[Anish9901]

We never deleted the file, we removed certain parts of it, basically, we don't want to remove the red lines, you can also see this from the diff of this PR.

[seancolsen]

Ahh I see. Sorry for the confusion! For some reason I thought the we deleted the file.