Making the "new repo" requests go faster

[Milton Miller II]

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.

milton