Re: master updated (18e7bc87521 -> c71a520d1da)

[Robert Pluim]

>>>>> On Mon, 7 Aug 2023 04:58:28 +0200, Stefan Kangas <stefankangas@gmail.com> 
>>>>> said:

    Stefan> Po Lu <luangruo@yahoo.com> writes:
    >> How can this be avoided?  I merely ran:
    >> 
    >> $ git merge --edit --no-ff feature/android
    >> 
    >> within a checkout of master; the --no-ff was necessary for supplying a
    >> ChangeLog entry for the merge itself.

    Stefan> That looks like the right way to do it, so this is a false alarm on 
my
    Stefan> end.  Sorry for the ruckus.

    Stefan> I believe that I got confused for a second there by the large number
    Stefan> of merge commits from master into feature/android. I think in the
    Stefan> future it would be beneficial if feature branch authors could try to
    Stefan> keep the number of merges from master a bit lower.

Like zero :-)

    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.

Robert
--