[gmx-developers] Unsquashed MR in master

Magnus Lundborg magnus.lundborg at scilifelab.se
Wed Oct 6 10:59:13 CEST 2021


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 <mailto: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
>     <mailto: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/c3a26b5a/attachment.html>


More information about the gromacs.org_gmx-developers mailing list