Re: Gitlab Migration

["João Távora" <joaotavora@gmail.com>]

João Távora <joaotavora@gmail.com> writes:

> On Sun, Aug 29, 2021, 09:23 Drew DeVault <sir@cmpwn.com> wrote:
>
>  On Sun Aug 29, 2021 at 10:21 AM CEST, Eli Zaretskii wrote:
>  > I no longer remember the exact details, it was something we bumped
>  > into during discussions when Emacs switched to Git. AFAIR, it had to
>  > do with working on a feature branch and frequently rebasing it onto
>  > the latest master (so that the feature branch doesn't diverge too
>  > much), then later merging from the feature branch to master.
>
>  Hm, weird. I would like to see some reproducible evidence of this so
>  that a deeper investigation can be done. I've used rebase thoroughly for
>  many years on hundreds of projects without any such incident.
>
> If the branch you're integrating via rebase happens to have merge
> commits of its own, and you don't pass and/or fully understand what
> --preserve-merges does, it's possible I think. If you always always
> merge, it doesn't happen. Neither does it if you always always rebase,
> I guess. So I guess the argument can be spun around into a
> counter-merge argument, I guess. Anyway, I'm a rebase lover myself.

I just realize I "guessed" about 50 thousand times there and was
basically handwaving.  I've tried a simple example of my own speculation
just now and couldn't reproduce.  Either my toy example was too
simplistic (it involved two branches, a single file and no conflicts
ever) or it's been somehow fixed in recent Git versions.

I still think it may happen if you mix rebase & merge.  Especially if
you merge from "unreliable branches", i.e. branches whose collaborators
are not entirely aware/proficient with the commit-duplicating
consequences of rebasing and/or cherry-picking.

This is a tangent, but we also have some practice here in Emacs which I
don't fully understand, which is to "merge back from release branches"
to integrate fixes from those branches into 'main'.  That in itself
already opens the doors to "duplicated commits" if special care isn't
taken.  That's because these merges are special: they somehow don't
contain all of the stuff that was present in the release branches.  See,
for example, this commit:

    commit 8ba6a38b3bccab6eda8e1962e4c8618704b9f83e
    Merge: 979f14e641 5b03849102
    Author: Glenn Morris <rgm@gnu.org>
    Date:   Wed Aug 25 07:51:41 2021 -0700
     
        ; Merge from origin/emacs-27
     
        The following commit was skipped:
     
        5b03849102 (origin/emacs-27) ; * test/lisp/files-tests.el: Add tests ...

I don't know if this practice is what constitutes an "evil merge", but
it's the way Emacs release management has worked (successfully, to the
best of my knowledge) for a good while.

João