Re: Is dist-git a good place for work?
On Thu, 14 May 2020 at 14:31, Ondřej Lysoněk <olysonek(a)redhat.com> wrote:
Hunor Csomortáni <csomh(a)redhat.com> writes:
> On Wed, May 6, 2020 at 10:24 PM Simo Sorce <simo(a)redhat.com> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org