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. 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
