Making the "new repo" requests go faster

[Ed Tanous]

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://gerrit.openbmc-project.xyz/c/openbmc/docs/+/41099   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?

>
> milton
>