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

[Eli Zaretskii <eliz@gnu.org>]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Thu, 01 Jun 2017 23:01:56 +0800
> 
> >>     Rename nnir.el to gnus-search.el
> >
> > Is this renaming really necessary?  If it isn't, I'd prefer not to
> > rename, as doing so makes digging into history harder.
> 
> When all the dust has cleared on these edits, gnus-search.el won't
> really have much to do with the original nnir.el, not to the point where
> you'd be interested in following code evolution from one file to the
> next. The "rename" commit message was more a note-to-self intermediate
> step.

Ah, okay.  In that case, the renaming really doesn't matter.  Thanks
for explaining this bit.

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

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

Thanks.