[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs-diffs Digest, Vol 175, Issue 8

From: Eric Abrahamsen
Subject: Re: Emacs-diffs Digest, Vol 175, Issue 8
Date: Fri, 02 Jun 2017 16:56:20 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Eric Abrahamsen <address@hidden>
>> Date: Thu, 01 Jun 2017 23:01:56 +0800

>> This actually leads to a question that I was going to ask later: with a
>> fairly hefty change like this, how should the code be later merged into
>> master?
> My preference is for you to simply merge the branch onto master.  This
> will leave all of your branch commits visible and bisect-able, so no
> information is lost.
>> My feeling is that, eventually, it might make most sense to merge with
>> --squash
> If you must.  The disadvantage is that finding the problematic change
> by bisecting will be harder, if that change is part of the single
> jumbo commit.

The problem is that there are very few stable intermediate states where
bisecting will actually be meaningful. When the branch is looking ready
to drop, I'll go through it and see where there are stable mid-points I
can preserve. My preference would still be to take all the "Fix last
commit" type commits and rebase them away -- there's no need to carry
over that kind of pollution into master. I'll keep as much of the
history in place as possible, though.

>> and just do a fairly hefty commit message.
> How to make a commit message is a separate problem.  I normally do
> that as a log message for the merge-commit (which by default is
> trivially generated by Git).  You can also do that as the last commit
> on the branch, or, if some changes are needed after the merge, in the
> log message of those changes.  In any case, I think this issue should
> not have any bearing on how to merge.

Yup, I was just thinking that if it was a --squash merge, that would be
a lot to talk about in one commit message. Preserving commit history
will help, and I'll what you mentioned with the log message for the
merge itself.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]