Description of problem: I think current working with pull requests and personal forks is unnecessary complicated. I lack some easy way to create my new fork from dist-git repository and add additional remote. Configuration of additional remote requires multiple steps, which tends to be quite repeated. If I want to work on forks on multiple packages with forks, I should create some scripts. I think it should be more easy to configure users fork. Maybe also include option to set my fork as git push url. For packages, where I lack commit access, git push would result in denied message anyway. If I could choose to create and push to my fork, it would speed up my contributions. fedpkg clone --fork-push # example to configure anonymous fetch, but push to my fork Version-Release number of selected component (if applicable): fedpkg-1.40-1.fc32.noarch Actual results: fedpkg clone $PACKAGE cd $PACKAGE git remote -v visit https://src.fedoraproject.org/rpms/$PACKAGE click fork wait until fork is finished click clone, select fork remote ssh url git remote add $USER $URL git fetch $USER # do some work git push $USER Expected results: fedpkg clone --fork $PACKAGE # or cd $PACKAGE fedpkg fork # not sure about the best name # just wait # do some work git push $USER Additional info: Because fedpkg can request branches and repositories, I think it could easily request also forks without web UI involved. I think it is related to Don't push knowingly broken or work-in-progress work to dist git [1] proposal. 1. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6ZZ3RPDCVZGWN5EICJV2ZMZBCEJ7R25B/
This already exists: fedpkg clone $PACKAGE cd $PACKAGE fedpkg fork git fetch $USER # do some work git push $USER The command is missing from bash completion it seems, but it should work.
A very useful enhancement to this would be a feature to reset any existing fork I have to match the upstream. For many people using this, they won't be closely following but may end up making PRs to the same package with a year in between.
(In reply to Matthew Miller from comment #2) > A very useful enhancement to this would be a feature to reset any existing > fork I have to match the upstream. For many people using this, they won't be > closely following but may end up making PRs to the same package with a year > in between. Wouldn't just git checkout master; git pull --rebase; git push --force $USER do just this thing exectly?
I would suggest making a new branch for each proposal. Just before creating PR, do git checkout -b <feature-branch-name>. Then regardless proposal was merged or not, master still does not conflict with recent development, even after 2 years. Ie do not make PR from fork's master, but have a branch for each PR. It would help, if there was checkbox to delete branch on merge. It is common on gitlab.
(In reply to Lubomír Sedlář from comment #1) > This already exists: > > fedpkg clone $PACKAGE > cd $PACKAGE > fedpkg fork > git fetch $USER > # do some work > git push $USER > > The command is missing from bash completion it seems, but it should work. Oh, correct, I have it already. Please fix bash completion, but otherwise feel free to close this bug. Option to --fork during clone would be helpful to me, but only a minor improvement over already existing fork feature.
(With regard to "git push $USER", if one does always fork and submit pull requests, one can simplify that by adding the Git configuration (for example): | [url "https://src.fedoraproject.org/forks/scfc/rpms/"] | pushInsteadOf = https://src.fedoraproject.org/rpms/ and optionally: | [push] | default = current Then one can (after "fedpkg clone -a" and "fedpkg fork") just "git push" and the reply from the Git server will include a link to submit a pull request.)
FEDORA-EPEL-2021-4b1bb0ee48 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-4b1bb0ee48
FEDORA-2021-20e5f8a6b8 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-20e5f8a6b8
FEDORA-2021-20e5f8a6b8 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-20e5f8a6b8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-20e5f8a6b8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-20e5f8a6b8 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.