[gmx-developers] Unsquashed MR in master

[Andrey Alekseenko]

Hi!

> It's a protected branch in gitlab, so there's probably some more ceremony
required.

It can be unprotected in one click on the
https://gitlab.com/gromacs/gromacs/-/settings/repository page, so no
problems with this part.

Dealing with all the people and machines that have already pulled the
current master is, IMHO, a bigger issue.

--
Best,
Andrey

On Wed, Oct 6, 2021 at 11:47 AM Mark Abraham <mark.j.abraham at gmail.com>
wrote:

> Hi,
>
> On Wed, 6 Oct 2021 at 11:41, Szilárd Páll <pall.szilard at gmail.com> wrote:
>
>> Hi,
>>
>> 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.
>>
>> Is there any action that implicitly unchecks the "Squash commits"
>> checkbox and that we can do something about in the gitlab configs?
>>
>
> 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
> do be on unless it is a merge commit. But last time I looked that was not
> an option.
>
>
>> Side-note: Mark, why do you think we could have not just force-pushed to
>> master to rewrite the branch?
>>
>
> It's a protected branch in gitlab, so there's probably some more ceremony
> required.
>
> Mark
>
> Cheers,
>> --
>> Szilárd
>>
>>
>> On Wed, Oct 6, 2021 at 10:59 AM Magnus Lundborg <
>> magnus.lundborg at scilifelab.se> wrote:
>>
>>> Hi everyone,
>>>
>>> As there hasn'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 'Merge'
>>> button for a while.
>>>
>>> Regards,
>>> Magnus
>>>
>>> On 2021-10-06 07:08, Mark Abraham wrote:
>>>
>>> Hi,
>>>
>>> I think it'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's pulled in the meantime, including projects that automatically
>>> mirror us (including our own mirror on github). That's a small amount of
>>> activity for some people. Doing nothing means that there'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'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'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.
>>>
>>> On Tue, 5 Oct 2021 at 18:57, Magnus Lundborg <
>>> magnus.lundborg at scilifelab.se> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> By mistake I merged an MR without squashing all commits today. The
>>>> question now is if we should try to restore the master branch and
>>>> rewrite the history or if we should let it be. Leaving it as it is
>>>> might
>>>> cause trouble with future 'git bisect' since some commits in between
>>>> might not compile or might fail tests. But on the other hand, rewriting
>>>> history is not optimal either, especially since there is at least one
>>>> commit merged afterwards. I think it could be good not to merge
>>>> anything
>>>> more until we have decided how to proceed. What do you think would be
>>>> best?
>>>>
>>>> I'm sorry about this mess.
>>>>
>>>> Regards,
>>>> Magnus
>>>>
>>>> --
>>>> Gromacs Developers mailing list
>>>>
>>>> * Please search the archive at
>>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
>>>> before posting!
>>>>
>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>>
>>>> * For (un)subscribe requests visit
>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>>>> or send a mail to gmx-developers-request at gromacs.org.
>>>>
>>>
>>>
>>> --
>>> Gromacs Developers mailing list
>>>
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>>> posting!
>>>
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>
>>> * For (un)subscribe requests visit
>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>>> or send a mail to gmx-developers-request at gromacs.org.
>>
>> --
>> Gromacs Developers mailing list
>>
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>> posting!
>>
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>> or send a mail to gmx-developers-request at gromacs.org.
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20211006/207a80fd/attachment-0002.html>