[gmx-developers] Unsquashed MR in master

[Szilárd Páll]

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?

Side-note: Mark, why do you think we could have not just force-pushed to
master to rewrite the branch?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20211006/ab789470/attachment-0002.html>