On Thu, 14 May 2020 at 14:31, Ondřej Lysoněk <olysonek@xxxxxxxxxx> wrote: > > Hunor Csomortáni <csomh@xxxxxxxxxx> writes: > > > On Wed, May 6, 2020 at 10:24 PM Simo Sorce <simo@xxxxxxxxxx> wrote: > >> Well, a way to allow force pushes would be to have a git hook that > >> branches the tree before the force push. (creating a branch named > >> something like audit-force-push-<timestamp>) > >> That way you can retain data for legal/auditing reasons, while allowing > >> every day history to be rewritten. > > > > Wouldn't it be easier to approach this from a build system perspective > > and let for example the build system (or tools) tag the commits which > > were built from with some for-ever-living tags? This would still > > ensure a complete audit trail for whatever was built and shipped, but > > could eliminate the need for a complete lock down of dist/source-git. > > > >> Not sure how "nice" that would be for an auditor that has to > >> reconstruct what happened over multiple force pushes that way, it also > >> will generate quite an amount of noisy metadata (branches), but it > >> could work. > > > > Refs created for auditing purposes could be kept in a separate git > > namespace so they don't create noise in everyday workflows. > > As someone who works with git history all the time, I cannot imagine how > I would work in such an environment. Consider the simple task of finding > the commit that first introduced a downstream change. Currently with > dist-git, I can just do 'git log patch-file', scroll to the very end and > be done with it. > It's a good point that this operation would be harder but it could be solved, I think. I mean it could have beneficial features for maybe not all packages but at least some. I suspect on such scale as Fedora operates, it might be quite hard to do something which improves things for everybody. > If what you're proposing was implemented, then I'd have to manually try > all the tags until I found the "right history" where the change was > first introduced. > > In an email in this thread clime suggested a similar approach, only > instead of tags there would be a separate branch for each upstream > release. While that eliminates the need to allow force-pushes, for the > purposes of digging through the history it's the same thing. The only > difference is that instead of iterating over tags, I'd be iterating over > branches. > > The only other approach to source-git that I can think of is merging new > upstream releases instead of git-rebasing on top of them. That is the > approach that I originally thought would work, but one of Neal's > responses made me realize that this approach also has a significant > drawback - it makes distinguishing between downstream changes and > cherry-picked upstream changes hard. > > I was originally excited about source-git, however currently I don't see > an approach to source-git that would work for me and I don't think I'd > use it if it became available. And frankly, I think I wouldn't want > other people using it either because it would make understanding their > packages hard. > > I completely agree that dist-git is difficult to work with, but perhaps > instead of inventing something completely new, we could focus on making > working with dist-git easier by dropping the changlog and Release from > the specfiles and on creating tools for ourselves to make working with > patches easier? I'm currently looking into Quilt, mentioned by several > people here, to see if it could make my life easier at all. Just a > suggestion. > > Thanks everyone for this enlightening thread. > > Ondřej Lysoněk > _______________________________________________ > 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 _______________________________________________ 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
