Making the "new repo" requests go faster

[Milton Miller II]

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.

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.

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.

milton