<div dir="ltr"><div>Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 6 Oct 2021 at 11:41, Szilárd Páll &lt;<a href="mailto:pall.szilard@gmail.com">pall.szilard@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>I agree with the decision, as there has been no vote (other than mine) for fixing the issue, it seems to be of no concern to the broader community, so we should move on.</div><div><br></div><div>Is there any action that implicitly unchecks the &quot;Squash commits&quot; checkbox and that we can do something about in the gitlab configs?</div></div></blockquote><div><br></div><div>Not that I know of. The config options let you choose the default status of that checkbox. We changed it to default on, which works well for us except that we would prefer it</div><div>do be on unless it is a merge commit. But last time I looked that was not an option.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Side-note: Mark, why do you think we could have not just force-pushed to master to rewrite the branch?</div></div></blockquote><div><br></div><div>It&#39;s a protected branch in gitlab, so there&#39;s probably some more ceremony required.</div><div><br></div><div>Mark</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Cheers,<br></div><div dir="ltr">--<br>Szilárd</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 6, 2021 at 10:59 AM Magnus Lundborg &lt;<a href="mailto:magnus.lundborg@scilifelab.se" target="_blank">magnus.lundborg@scilifelab.se</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <div>Hi everyone,</div>
    <div><br>
    </div>
    <div>As there hasn&#39;t been (m)any votes (on
      this list) for rewriting history to fix these commits the
      consensus now seems to be that we go on from the current state and
      proceed merging into master again. I hope this will not cause too
      much problems. For now I, myself, will not push the &#39;Merge&#39; button
      for a while.<br>
    </div>
    <div><br>
    </div>
    <div>Regards,</div>
    <div>Magnus<br>
    </div>
    <div><br>
    </div>
    <div>On 2021-10-06 07:08, Mark Abraham
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi,
        <div><br>
        </div>
        <div>I think it&#39;s clear to follow normal practice and not
          rewrite history. Doing so means we have to rename master,
          delete it, push a fixed one, organize to replace the updated
          content, and then fix/delete the repo of anybody who&#39;s pulled
          in the meantime, including projects that automatically mirror
          us (including our own mirror on github). That&#39;s a small amount
          of activity for some people. Doing nothing means that there&#39;s
          a chance in future of someone doing a bisection and hitting
          one of these 24 commits that might not build or might fail a
          test. If they do, most of the time they&#39;ll see that the
          failure mode is different and they can move to a different
          nearby commit and try again. This is already what they would
          have to do if the case they&#39;re investigated was something that
          only failed in post-submit testing or the pre-submit testing
          that is not a formal requirement for gitlab to permit an MR to
          be submitted.</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue, 5 Oct 2021 at 18:57,
          Magnus Lundborg &lt;<a href="mailto:magnus.lundborg@scilifelab.se" target="_blank">magnus.lundborg@scilifelab.se</a>&gt;
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi
          everyone,<br>
          <br>
          By mistake I merged an MR without squashing all commits today.
          The <br>
          question now is if we should try to restore the master branch
          and <br>
          rewrite the history or if we should let it be. Leaving it as
          it is might <br>
          cause trouble with future &#39;git bisect&#39; since some commits in
          between <br>
          might not compile or might fail tests. But on the other hand,
          rewriting <br>
          history is not optimal either, especially since there is at
          least one <br>
          commit merged afterwards. I think it could be good not to
          merge anything <br>
          more until we have decided how to proceed. What do you think
          would be best?<br>
          <br>
          I&#39;m sorry about this mess.<br>
          <br>
          Regards,<br>
          Magnus<br>
          <br>
          -- <br>
          Gromacs Developers mailing list<br>
          <br>
          * Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a>
          before posting!<br>
          <br>
          * Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
          <br>
          * For (un)subscribe requests visit<br>
          <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a>
          or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
        </blockquote>
      </div>
      <br>
      <fieldset></fieldset>
    </blockquote>
    <p><br>
    </p>
  </div>

-- <br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div>
-- <br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div></div>