On Fri, Apr 1, 2022 at 12:52 PM Michael J Gruber <mjg@xxxxxxxxxxxxxxxxx> wrote: > In particular, this would allow to avoid the many "commit missing patch", "actually commit the change", > "duh" commits which happen after a successful `fedpkg build --scratch --srpm` followed by a half-(how do you say this nicely)ed commit. It would also allow to: 1/ messing with other people repositories 2/ ability to rewrite other contributor's work - even RelEngs and Proven Packager's The advice - even though only partial - really is "write better code". No one ever will write error-less code. But there are a lot of steps you can take to reduce the amount of errors in your code - testing of your own code and code review being amongst the first steps before pushing anything to production. And even when you push an error, there is no shame in correcting yourself. (This is the second part of the advice) It is a healthy behaviour to openly step out and correct what you messed up, rather than trying to hide it from everyone. Openness and trust are values this community is built upon. We already have so many ways to reduce errors in our code. 1/ Use pull requests from your forks instead of pushes directly to production branches 2/ You can ask people to review your code 3-A/ you can set up ZUUL CI to make a mock build for you 3-B/ or you can do mock build yourself 3-C/ or you can make a scratch build 4/ ZUUL CI can also run rpminspect and more to uncover a whole bunch of issues you would never find yourself 5/ Learn git better to ease your work with it e.g. never making more than a single change in a single commit That way your commits can be perfectly revertible - which is one of the intended ways to fix your errors I believe you look at it from the wrong end. Why wouldn't you try to avoid pushing the erroneous code in the first place - e.g. by testing ? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Fri, Apr 1, 2022 at 12:52 PM Michael J Gruber <mjg@xxxxxxxxxxxxxxxxx> wrote: > > Hi there > > I know why we do not allow to force push to dist-git in the rpms namespace, but I am wondering whether we can implement this more in line with the reason: > > dist-git has to be a permanent record for the "source" (spec etc.) against which a package is built, but currently we deny pushing even when there is no build against the rewritten commits. Instead, I suggest the following behaviour for the update-hook of git-receive-pack: > > - check which commit contained in "old object name" is the most recent one (topology order) which has been built (successfully) - call it "old build object name" > - check whether the "new object name" is descendant of (contains) "old build object name" (rather than "old object name", which would forbid any force push) > > This would allow to rewrite a branch as long as the last commit hasn't been built yet (but allow only rewrites to commits since the last build). In particular, this would allow to avoid the many "commit missing patch", "actually commit the change", "duh" commits which happen after a successful `fedpkg build --scratch --srpm` followed by a half-(how do you say this nicely)ed commit. > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
