clime <clime@xxxxxxxxxxxxxxxxx> writes: > 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 think that source-git could make sense for packages that have historically *not* had many patches - be that downstream or cherry-picked patches. (And I realize that is quite the opposite of what others have said here.) With such packages, I could just git-pull new upstream releases, review the changes and git-push them to Fedora, instead of having to juggle with tarballs. That's a very appealing proposition to me. And with such packages, you wouldn't run into the downside of accumulating a history that is hard to understand. So my opinion is that for simple packages that have no patches and where the conversion between source-git and dist-git is relatively straightforward, source-git could be a great option. For other packages, not really. > > I suspect on such scale as Fedora operates, it might be quite hard to > do something which improves things for everybody. Agreed. Ondřej > >> 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
