Re: dist-git force push

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux