Closed zoshua closed 4 months ago
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.
:white_check_mark: masqu3rad3
:white_check_mark: zoshua
:x: joshochoa
Great news, thanks. So I think the reason tests don't run here is because of that CLA. It looks like you are both @zoshua and @joshochoa except @joshochoa is not a GitHub user.
Would it be possible to squash your commits, such that they are all committed under the same user?
From there, what's missing is tests actually running for PySide6. Currently, we only test whether the changes pass for Qt 4 and 5. For Qt 6, I expect we'll need to update the Dockerfile to include PySide6.
Spent all morning trying to figure out the best way to 'fix' the orphaned user situation but have not really come up with a straightforward/elegant solution just yet.
Unfortunately there is no clear easy squash on my end that I could find in Github WebApp or Desktop.
The current solve is looking like a serious rewriting of the commit history using something like git filter-repo or git filter-branch.
This is definitely new territory for me, if you/anyone reading this has creative fixes I am happy to implement, lmk.
This piqued my interest, and re-affirmed why I avoid merge commits like the plague in feature branches, they make updating the history of a feature branch branch harder. The merging in of the newer commits in mottosso:master made simple squashing difficult.
I tried a few things but I had the most success with generating a patch file based on this. It will squash all commits into a single new commit on top of the latest commit in mottosso:master.
I recommend making these changes on your working copies master branch so you don't need to create a new pull request.
git reset --hard <...>
to reset the broken branch back to the original value.2c0f4dc596204670f4597b841821cff8a171c3a2
, I'll refer to it as <qt_py_hash>
.git diff <qt_py_hash> HEAD -- > updates.dif
. This shows the sum of all changes between your branch and Qt.py, ie what we see in the changes tab of this MR.git reset --hard <qt_py_hash>
again using the qt_py_hash. At this point your branch is exactly the same as mottosso:master.git apply --stat updates.diff
and git apply --check updates.diff
mentioned in the stack overflow article, but they are just checking if the patch will apply.git am
command to work due to a empty ident name, but that seems to be actually committing the changes, you can just run git apply updates.diff
. This apples your code changes as working copy changes.As this involves rebasing and force pushing, I'll add the obligatory warning that you should (almost)never rewrite the history of a master branch other people are using. As zoshua:master is your fork and I'm guessing you are the only user of I'm not worried, but at this point if mottosso were to do stuff like this to mottosso:master it would annoy every other user was working on a fork of it. For future merge requests I would recommend making a feature branch not directly editing zoshua:master.
@MHendricks Thank you so much for this write up!
I totally goofed on not working from a feature branch in the first place.
I will run through the process asap and let you know if I hit any snags.
Eek, complicated. Since we are only interested in 1 file, I would recommend:
Now you've "squashed" it and we can PR and merge that instead.
Now passing new testing framework!