Making the "new repo" requests go faster

[Ed Tanous]

On Tue, Mar 9, 2021 at 10:24 AM Milton Miller II <miltonm at us.ibm.com> wrote:
>
> On March 9, Ed Tanous <ed at tanous.net> wrote:
> >On Tue, Mar 9, 2021 at 9:32 AM Milton Miller II <miltonm at us.ibm.com>
> >wrote:
> >>
> >> On March 9, Brad Bishop wrote:
> >> >On Tue, Mar 9, 2021 at 5:57 AM Brad Bishop
> >> ><bradleyb at fuzziesquirrel.com> wrote:
> >> >> On Fri, Mar 05, 2021 at 11:02:24AM -0800, Ed Tanous wrote:
> >> >> >On Fri, Feb 5, 2021 at 12:02 PM Ed Tanous <ed at tanous.net>
> >wrote:
> >> >> >>
> >> >> >> In an effort to fix these issues and more, I'd like to
> >propose
> >> >> >> creating a new repository for a "new daemon" template.
> >> >> >
> >> >> >If anyone is following this thread still, patches have been
> >pushed
> >> >> >to
> >> >>
> >>https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-
> >2Dproject.xyz_c_openbmc_docs_-2B_41099&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1
> >ZOg&r=bvv7AJEECoRKBU02rcu4F5DWd-EwX8As2xrXeO9ZSo4&m=zOJQ8qDYu5wBWzKub
> >6P9N-WKFD3SB3DdgsAsegfH5xQ&s=iLLTE_nLMY6TUpL-Q4U6xtZoUdNkXSDwdlMskft8
> >vIU&e=    for the
> >> >> >moment.  As they get closer to approval, I'd like to get a new
> >> >> >template repo created to house the code contained in that
> >patch,
> >> >> >and
> >> >> >CI setup on said repo if I could.
> >> >>
> >> >> Thanks Ed!
> >> >>
> >> >> The only reason I haven't created this already was I wasn't sure
> >> >> what to
> >> >> call it.  Any ideas on a name out there?
> >> >
> >> >No worries.  I don't really have a strong opinion on what it's
> >called
> >> >either.  The ideas I've had so far were "Sample app" or "example
> >> >app".
> >>
> >>
> >> One thing I wanted to point out when we are adopting this.
> >>
> >> Git has a feature that it purposely checks the oldest ancestor of
> >> the target repository against the source repository.  This is a
> >> check that helps prevent pushing an unrelated tree.
> >>
> >> From the git push man page:
> >>
> >>        -f, --force
> >>            Usually, the command refuses to update a remote ref that
> >is not an
> >>            ancestor of the local ref used to overwrite it. This
> >flag disables
> >>            the check. This can cause the remote repository to lose
> >commits;
> >>            use it with care.
> >>
> >>
> >> If we give instructions to rebase the commits when creating a new
> >> repository the new commit time and/or committer will cause a unique
> >> hash and we will not defeat this check.
> >
> >I'm not really following why this would be a concern for this kind of
> >thing.  Sure, force push is a big hammer, and should be used with
> >discretion and care, but I'm not seeing why we would ever have that
> >problem on a new repo, regardless of if we squashed the template repo
> >history (which would be my preference as the template repo history is
> >irrelevant to a new repo) or whether we pushed it as-is with the
> >template repo history.  I can't think of a workflow where we would
> >rebase, but maybe I'm missing something?
> >
> >Can you elaborate on what the exact concern is?
>
> User starts with template repository and adds content for app A.
>
> User starts with template repository adding files for content B.
>
> User accidentlly recalls pull command for repository A when
> working in repository B.
>
> If the commits were rebased git complains.

I think I get this, this would really only be a concern for whomever
is writing commit 1, right?  Presumably everyone else would be cloning
from the new repo, which would have a completely disparate history.
Hopefully nobody else is pulling directly from the template repo.
Based on the MAINTAINERS files, the gerrit admins would retain control
on the repo until the MAINTAINERS file is pushed, and are hopefully
schooled enough to avoid this kind of thing.

>
> If the repositories share a common ancestor then the content
> of A is merged into repository B.  At a minimum the user has
> unrelated content to purge.  In a worse case the content of
> the second repository is relatively small and doesn't get
> caught in the review process.

In theory the only changes they'd get here would be if we update the
template repo, in which case, we probably want the changes in the new
thing?

>
> Rebasing to get an updated commit time allows this check to
> remain effective.   The Author history including timestamps
> can be preserved.
>
> I thought about saying merge this into your repository would
> work but then I realized there is a common ancestor in the
> middle which may defeat the checking.
>

Overall, yeah, this a concern, but I'm not sure what we can do about
it to mechanically limit it from happening in git;  If there's any way
we can structure the template repo to avoid this, I'm open to
suggestions.  When I add the readme to the commit (coming soon) I'll
be sure to put renaming the origin remote as one of the steps.

> milton
>