search

python-qt-tools / PyQt5-stubs

Stubs for PyQt5
GNU General Public License v3.0
66 stars 31 forks source link

Merge upstream 5.15.2 #116

Closed altendky closed 3 years ago

BryceBeagle commented 3 years ago

Should this be merged from https://github.com/stlehmann/PyQt5-stubs/tree/upstream instead? It may not matter?

Maybe the duplicate title with https://github.com/stlehmann/PyQt5-stubs/pull/113 is throwing me off and this is different?

altendky commented 3 years ago

@BryceBeagle, as I recall I did it this way before. I pulled a branch off master, merged in upstream, then submitted a PR. Do you like that? No?

About the names, uh, yeah. Hmm... perhaps we ought to name these differently. :|

altendky commented 3 years ago

I forget if I had any big reason for this structure or not. I guess maybe I just have in my head that after a branch is merged it dies, which certainly isn't required. Though, I guess this format let's us do merge cleanup work explicitly somewhere without pushing to either upstream or master. So, I guess that's the bit that matters. Also, making sure tests are passing and such.

(side note, looks like I need to flip this over to GitHub Actions given the Travis situation...)

BryceBeagle commented 3 years ago

I figured that the workflow would have been

altendky/upstream merge into stlehmann/upstream then stlehmann/upstream merge into stlehmann/master

But it looks like stlehmann/upstream and altendky/merge_upstream_5.15.2 don't have the same commit history? I would have expected them to be the same after #113. Maybe I'm just getting confused by something simple here?

altendky commented 3 years ago

I don't edit upstream branches in my forks (mostly). So I pulled a branch off upstream as altendky:upstream_5.15.2 https://github.com/stlehmann/PyQt5-stubs/pull/113. That got merged into upstream. I then pulled altendky:merge_upstream_5.15.2 (probably a terrible name) from master because I was making a PR against master. I then merged in upstream (which includes 5.15.2). For all I know I'll need to make some commits to make tests pass etc, maybe. So, it's useful to not be doing this on either upstream (which should be purely upstream) nor master (which should always be passing tests etc.

Another perspective, I like to have my PRs be up to date with their target branch prior to merging them. We also don't want to merge master into upstream. So, this requires a branch separate from both for the PR.

I think my next stop will be a diagram if we need. :]