clime <clime(a)fedoraproject.org> writes:
On Thu, 14 May 2020 at 14:31, Ondřej Lysoněk
> 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 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,
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
> 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
> Thanks everyone for this enlightening thread.
> Ondřej Lysoněk