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

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

[Eli Zaretskii]

> From: emacs-diffs-request@gnu.org
> Date: Thu, 01 Jun 2017 03:50:45 -0400
> 
> From: eric@ericabrahamsen.net (Eric Abrahamsen)
> To: emacs-diffs@gnu.org
> Date: Thu,  1 Jun 2017 03:50:19 -0400 (EDT)
> Subject: [Emacs-diffs] scratch/gnus-search a80b6f9 02/30: Rename nnir.el to
>  gnus-search.el
> Message: 1
> 
> branch: scratch/gnus-search
> commit a80b6f9da4d739c91d26c8c944c3b95ac87eac8a
> Author: Eric Abrahamsen <eric@ericabrahamsen.net>
> Commit: Eric Abrahamsen <eric@ericabrahamsen.net>
> 
>     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.

TIA

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

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: emacs-diffs-request@gnu.org
>> Date: Thu, 01 Jun 2017 03:50:45 -0400
>> 
>> From: eric@ericabrahamsen.net (Eric Abrahamsen)
>> To: emacs-diffs@gnu.org
>> Date: Thu,  1 Jun 2017 03:50:19 -0400 (EDT)
>> Subject: [Emacs-diffs] scratch/gnus-search a80b6f9 02/30: Rename nnir.el to
>>  gnus-search.el
>> Message: 1
>> 
>> branch: scratch/gnus-search
>> commit a80b6f9da4d739c91d26c8c944c3b95ac87eac8a
>> Author: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Commit: Eric Abrahamsen <eric@ericabrahamsen.net>
>> 
>>     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.

(Possibly extraneous background: half of the original nnir.el file is
getting moved into a new Gnus backend in nnselect.el, the remaining half
is mostly rewritten, and the "nnir" designation no longer makes any
sense. In fact, more actual code survives in nnir.el-->nnselect.el than
survived nnir.el-->gnus-search.el.)

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? It doesn't really make sense as a multi-commit patch-set,
because the whole thing basically got tossed out and re-written. There
is no viable "intermediate state", it's pretty much monolithic.

My feeling is that, eventually, it might make most sense to merge with
--squash and just do a fairly hefty commit message. If that happens, the
"rename" would just disappear: nnir.el would go away, and be replaced by
a combination of nnselect.el and gnus-search.el.

WDYT?

Anyway, I agree with Ted's suggestion that scratch branches maybe
shouldn't trigger emacs-diffs notifications!

Eric

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

[Eli Zaretskii]

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

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

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> 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.

Thanks,
Eric

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

[Philippe Vaucher]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

>
> Is this renaming really necessary?  If it isn't, I'd prefer not to
> rename, as doing so makes digging into history harder.
>

Hum, `git log` has `--follow` which works quite well and `git blame` tracks
content changes anyway (not file names).
The only "gotcha" when renaming a file is to avoid changing its contents as
well, otherwise it makes detection more difficult.

Or maybe you meant something else?

Philippe

[-- Attachment #2: Type: text/html, Size: 833 bytes --]

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

[Eli Zaretskii]

> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Thu, 1 Jun 2017 17:37:11 +0200
> Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, Emacs developers <emacs-devel@gnu.org>
> 
>  Is this renaming really necessary? If it isn't, I'd prefer not to
>  rename, as doing so makes digging into history harder.
> 
> Hum, `git log` has `--follow` which works quite well and `git blame` tracks content changes anyway (not file
> names).
> The only "gotcha" when renaming a file is to avoid changing its contents as well, otherwise it makes detection
> more difficult.

Yes, some Git commands can follow renaming, but others cannot, at
least not easily.  For example, "git log -L" has problems when it
crosses the renaming.  I had more trouble with other commands, which I
cannot at the moment recall; at the very least one needs to use
unusual syntax or non-default options which are hard to remember, so
that gets in the way when you have the least time.

So renaming is okay if we really have to do that, but we shouldn't do
it just because we can.