Re: master updated (18e7bc87521 -> c71a520d1da)

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Po Lu <luangruo@yahoo.com>,  emacs-devel@gnu.org
> Date: Wed, 09 Aug 2023 10:24:25 +0200
> 
>     Stefan> In admin/notes/repo we have this advice:
> 
>     Stefan>     In general, when working on some feature in a separate 
> branch, it is
>     Stefan>     preferable not to merge from master until you are done with 
> the
>     Stefan>     feature.
> 
> Which is why you should rebase in that situation, but some people
> donʼt like rebase for reasons that I donʼt quite understand. "It was
> slightly broken in a version of git from a decade ago" is not a valid
> argument: emacs developers should be expected to update their
> tools. <duck>
> 
>     Stefan> Perhaps we could expand it with some advice that would be more
>     Stefan> directly applicable to long-living and "large" feature branches 
> (such
>     Stefan> as android and nativecomp), where postponing the merge until the 
> end
>     Stefan> might be impractical.
> 
> See my previous paragraph.

There's no reason to rebase (although if someone wants that, they can
do it).  The preferred workflow for feature branches is to merge from
master only once, just before you are going to land the feature.  Then
test the results of the merge as well as possible, and merge back.

The usual reason that people merge from master is because they are
afraid of master breaking their feature or afraid of merge conflicts.
But these dangers are quite illusory, and if one works on a feature
that is completely new (as in this case), neither of the two dangers
is real.