Re: master updated (18e7bc87521 -> c71a520d1da)

[Po Lu <luangruo@yahoo.com>]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> 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>

Rebase isn't possible on feature branches, AFAIK, as they demand force
pushes.