* Re: Emacs-diffs Digest, Vol 175, Issue 8 [not found] <mailman.75394.1496303445.22740.emacs-diffs@gnu.org> @ 2017-06-01 14:26 ` Eli Zaretskii 2017-06-01 15:01 ` Eric Abrahamsen 2017-06-01 15:37 ` Philippe Vaucher 0 siblings, 2 replies; 6+ messages in thread From: Eli Zaretskii @ 2017-06-01 14:26 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs-diffs Digest, Vol 175, Issue 8 2017-06-01 14:26 ` Emacs-diffs Digest, Vol 175, Issue 8 Eli Zaretskii @ 2017-06-01 15:01 ` Eric Abrahamsen 2017-06-02 6:18 ` Eli Zaretskii 2017-06-01 15:37 ` Philippe Vaucher 1 sibling, 1 reply; 6+ messages in thread From: Eric Abrahamsen @ 2017-06-01 15:01 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs-diffs Digest, Vol 175, Issue 8 2017-06-01 15:01 ` Eric Abrahamsen @ 2017-06-02 6:18 ` Eli Zaretskii 2017-06-02 8:56 ` Eric Abrahamsen 0 siblings, 1 reply; 6+ messages in thread From: Eli Zaretskii @ 2017-06-02 6:18 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs-diffs Digest, Vol 175, Issue 8 2017-06-02 6:18 ` Eli Zaretskii @ 2017-06-02 8:56 ` Eric Abrahamsen 0 siblings, 0 replies; 6+ messages in thread From: Eric Abrahamsen @ 2017-06-02 8:56 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs-diffs Digest, Vol 175, Issue 8 2017-06-01 14:26 ` Emacs-diffs Digest, Vol 175, Issue 8 Eli Zaretskii 2017-06-01 15:01 ` Eric Abrahamsen @ 2017-06-01 15:37 ` Philippe Vaucher 2017-06-01 17:44 ` Eli Zaretskii 1 sibling, 1 reply; 6+ messages in thread From: Philippe Vaucher @ 2017-06-01 15:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Eric Abrahamsen, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs-diffs Digest, Vol 175, Issue 8 2017-06-01 15:37 ` Philippe Vaucher @ 2017-06-01 17:44 ` Eli Zaretskii 0 siblings, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2017-06-01 17:44 UTC (permalink / raw) To: Philippe Vaucher; +Cc: eric, emacs-devel > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-06-02 8:56 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <mailman.75394.1496303445.22740.emacs-diffs@gnu.org> 2017-06-01 14:26 ` Emacs-diffs Digest, Vol 175, Issue 8 Eli Zaretskii 2017-06-01 15:01 ` Eric Abrahamsen 2017-06-02 6:18 ` Eli Zaretskii 2017-06-02 8:56 ` Eric Abrahamsen 2017-06-01 15:37 ` Philippe Vaucher 2017-06-01 17:44 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.