* Missing changes in merges from emacs-25 to master @ 2016-03-20 11:36 martin rudalics 2016-03-20 17:32 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2016-03-20 11:36 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel Hi, Paul and friends Something in these commits seems to have made earlier changes to master reverted: commit cb4e054e41cdb7e398351a5ae8224759e721349e Merge: e6d5753 6090275 Author: Paul Eggert <eggert@cs.ucla.edu> Date: Sat Jan 30 11:43:26 2016 -0800 - commit 2b41d6a979b0ea361e078891b8763b4ae7be8092 Merge: fe9c8b6 71468e0 Author: Paul Eggert <eggert@cs.ucla.edu> Date: Sat Jan 30 11:28:37 2016 -0800 - commit 82b089783e71b2aeef950eaecfe4cbc0735e64a2 Merge: d27c807 f7dc6d8 Author: Paul Eggert <eggert@cs.ucla.edu> Date: Sat Jan 30 11:27:34 2016 -0800 - In particular, in commit aa636c8465b03c09249dccd68fca3d1df04eaa2c Eli fixed a bug in window.c by writing m->total_cols = new_size; instead of the earlier m->total_cols = size; IIUC after commit 82b089783e71b2aeef950eaecfe4cbc0735e64a2 the earlier line reappeared. Can you please have a look? I somehow have the feeling that more such issues might have occurred but I can easily be wrong. Worse even, I could have introduced such a bug myself in one of my later commits but don't see any evidence so far :-( Thanks, martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-20 11:36 Missing changes in merges from emacs-25 to master martin rudalics @ 2016-03-20 17:32 ` Eli Zaretskii 2016-03-20 18:38 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-20 17:32 UTC (permalink / raw) To: martin rudalics; +Cc: eggert, emacs-devel > Date: Sun, 20 Mar 2016 12:36:07 +0100 > From: martin rudalics <rudalics@gmx.at> > Cc: emacs-devel <emacs-devel@gnu.org> > > Hi, Paul and friends > > Something in these commits seems to have made earlier changes to master > reverted: > > > commit cb4e054e41cdb7e398351a5ae8224759e721349e > Merge: e6d5753 6090275 > Author: Paul Eggert <eggert@cs.ucla.edu> > Date: Sat Jan 30 11:43:26 2016 -0800 > > - > > commit 2b41d6a979b0ea361e078891b8763b4ae7be8092 > Merge: fe9c8b6 71468e0 > Author: Paul Eggert <eggert@cs.ucla.edu> > Date: Sat Jan 30 11:28:37 2016 -0800 > > - > > commit 82b089783e71b2aeef950eaecfe4cbc0735e64a2 > Merge: d27c807 f7dc6d8 > Author: Paul Eggert <eggert@cs.ucla.edu> > Date: Sat Jan 30 11:27:34 2016 -0800 > > - How did you conclude that these commits are the culprit? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-20 17:32 ` Eli Zaretskii @ 2016-03-20 18:38 ` martin rudalics 2016-03-20 18:50 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2016-03-20 18:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, emacs-devel > How did you conclude that these commits are the culprit? Running git diff fbce4757a874cc43806eb41b8637538b101c3c69..82b089783e71b2aeef950eaecfe4cbc0735e64a2 src/window.c gets me diff --git a/src/window.c b/src/window.c index 8953d3c..add2de3 100644 --- a/src/window.c +++ b/src/window.c @@ -35,13 +35,15 @@ #include "dispextern.h" #include "blockinput.h" #include "termhooks.h" /* For FRAME_TERMINAL. */ -#include "xwidget.h" #ifdef HAVE_WINDOW_SYSTEM #include TERM_HEADER #endif /* HAVE_WINDOW_SYSTEM */ #ifdef MSDOS #include "msdos.h" #endif +#ifdef HAVE_XWIDGETS +# include "xwidget.h" +#endif static ptrdiff_t count_windows (struct window *); static ptrdiff_t get_leaf_windows (struct window *, struct window **, @@ -3971,11 +3973,9 @@ depends on the value of (window-start WINDOW), so if calling this } -/* Resize frame F's windows when F's width or height is set to SIZE. - If HORFLAG is zero, F's width was set to SIZE, otherwise its height - was set. SIZE is interpreted in F's canonical character units - (a.k.a. "columns" or "lines"), unless PIXELWISE is non-zero, which - means to interpret SIZE in pixel units. */ +/* Resize frame F's windows when number of lines of F is set to SIZE. + HORFLAG means resize windows when number of columns of F is set to + SIZE. PIXELWISE means to interpret SIZE as pixels. */ void resize_frame_windows (struct frame *f, int size, bool horflag, bool pixelwise) { @@ -4076,7 +4076,7 @@ depends on the value of (window-start WINDOW), so if calling this m = XWINDOW (mini); if (horflag) { - m->total_cols = new_size; + m->total_cols = size; m->pixel_width = new_pixel_size; } else @@ -4371,7 +4371,9 @@ SIDE t (or `right') specifies that the new window shall be located on /* Block input. */ block_input (); +#ifdef HAVE_XWIDGETS xwidget_view_delete_all_in_window (w); +#endif window_resize_apply (p, horflag); /* If this window is referred to by the dpyinfo's mouse highlight, invalidate that slot to be safe (Bug#9904). */ @@ -7263,7 +7265,7 @@ Value is a list of the form (WIDTH COLUMNS VERTICAL-TYPE HEIGHT LINES If this variable is t, splitting a window tries to get the space proportionally from all windows in the same combination. This also -allows splitting a window that is otherwise too small or of fixed size. +allows to split a window that is otherwise too small or of fixed size. Resizing and deleting a window proportionally resize all windows in the same combination. What do you get? martin ^ permalink raw reply related [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-20 18:38 ` martin rudalics @ 2016-03-20 18:50 ` Eli Zaretskii 2016-03-20 19:15 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-20 18:50 UTC (permalink / raw) To: martin rudalics; +Cc: eggert, emacs-devel > Date: Sun, 20 Mar 2016 19:38:17 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: eggert@cs.ucla.edu, emacs-devel@gnu.org > > > How did you conclude that these commits are the culprit? > > Running > > git diff fbce4757a874cc43806eb41b8637538b101c3c69..82b089783e71b2aeef950eaecfe4cbc0735e64a2 src/window.c What is fbce4757a874cc43806eb41b8637538b101c3c69, and how is it related to the issue? My problem is that "git log -L" doesn't show my change at all, although searching through "git log src/window.c" I do see it. So I'm inclined to trust nothing I see about this particular matter. E.g., are we sure this didn't happen as part of the merges from emacs-25? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-20 18:50 ` Eli Zaretskii @ 2016-03-20 19:15 ` martin rudalics 2016-03-21 7:36 ` Paul Eggert 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2016-03-20 19:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, emacs-devel > What is fbce4757a874cc43806eb41b8637538b101c3c69, and how is it > related to the issue? It's the last commit before 82b089783e71b2aeef950eaecfe4cbc0735e64a2 that affects window.c (if I can trust C-x v l in this regard). commit 82b089783e71b2aeef950eaecfe4cbc0735e64a2 Merge: d27c807 f7dc6d8 Author: Paul Eggert <eggert@cs.ucla.edu> Date: Sat Jan 30 11:27:34 2016 -0800 - commit fbce4757a874cc43806eb41b8637538b101c3c69 Author: Alan Mackenzie <acm@muc.de> Date: Sun Jan 24 20:30:39 2016 +0000 > My problem is that "git log -L" doesn't show my change at all, > although searching through "git log src/window.c" I do see it. So I'm > inclined to trust nothing I see about this particular matter. E.g., > are we sure this didn't happen as part of the merges from emacs-25? I'm quite confident that it did happen as part of these merges. That's why I asked for clarification. I mentioned earlier here that IMO some commits were lost during the merges, but this change (and that of the comment that precedes it) are the first ones I could locate. I have no idea how to find the merge that caused the loss of these two changes. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-20 19:15 ` martin rudalics @ 2016-03-21 7:36 ` Paul Eggert 2016-03-21 9:22 ` martin rudalics 2016-03-21 16:06 ` Eli Zaretskii 0 siblings, 2 replies; 68+ messages in thread From: Paul Eggert @ 2016-03-21 7:36 UTC (permalink / raw) To: martin rudalics; +Cc: John Wiegley, Eli Zaretskii, emacs-devel As near as I can make out, the changes in this commit: commit aa636c8465b03c09249dccd68fca3d1df04eaa2c Author: Eli Zaretskii <eliz@gnu.org> Date: Fri Jan 15 17:07:38 2016 +0200 Fix crashes when mini-window has non-zero margins were first lost in this merge commit: commit 7823745acbe9b87eea2db4ef434e379fc903ec35 Merge: 6acd2aa bb0cd31 Author: John Wiegley <johnw@newartisans.com> Date: Mon Jan 18 22:56:33 2016 -0800 ; Merge from origin/emacs-25 The following commit was skipped: bb0cd31 Merge branch 'emacs-25' of git.sv.gnu.org:/srv/git/emacs into emacs-25 This merge commit skips a merge, which I think causes this particular problem. This merge commit is a parent of: commit 140016558bcb462692d8b9f2f3f866e0f337d218 Merge: 7823745 3ae7934 Author: John Wiegley <johnw@newartisans.com> Date: Mon Jan 18 22:56:34 2016 -0800 Merge from origin/emacs-25 3ae7934 ; * etc/NEWS: Mark entries that don't need further treatment. 6165c36 * lisp/files.el (dir-locals--all-files): Respect absolute file-names 2ffdf15 * lisp/help-fns.el (describe-variable): Fix a left-over parenthesis 71ecd62 * lisp/dired-x.el (dired-omit-here-always): Use add-dir-local-variable f0b82b3 * lisp/files.el (dir-locals--all-files): Use completion instead of wildcards 86e4513 Fix incompatbilities with MS-Windows 2000 and older 4e96521 Mention in PROBLEMS an issue with MS-Windows NT4 15c23aa Ensure 8-byte aligned memory allocation on MS-Windows 9X 39afa42 Fix tests for active region in hideif.el 05df666 Fix interactive specs in some hideif.el commands which in turn is a parent of: commit bca49307c8ea3f96d6eede375a7f42091ae5d5af Merge: 1400165 6e79b63 Author: John Wiegley <johnw@newartisans.com> Date: Mon Jan 18 22:56:34 2016 -0800 ; Merge from origin/emacs-25 The following commit was skipped: 6e79b63 ; Auto-commit of loaddefs files. which in turn is a parent of: commit 1b76d9168336ede8976b980aeaed64ae2908501a Merge: bca4930 2e5a89f Author: John Wiegley <johnw@newartisans.com> Date: Mon Jan 18 22:59:51 2016 -0800 - which in turn is a parent of: commit b895c72059521fec064ff27b4cfcfa4104081c4e Merge: badcd38 1b76d91 Author: Vincent Belaïche <vincentb1@users.sourceforge.net> Date: Wed Jan 20 08:30:51 2016 +0100 Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs which leads via a long thin graph to the merge commit 82b089783e71b2aeef950eaecfe4cbc0735e64a2 that you identified as losing the change. One of the entries in that graph is this commit: commit 64a568d6100e5eab5b86e8bd31846212654d1fcf Author: Eli Zaretskii <eliz@gnu.org> Date: Wed Jan 20 11:47:19 2016 +0200 Fix MS-Windows build broken by a botched merge from emacs-25 * src/w32.c (w32_crypto_hprov): New static variable. (globals_of_w32): Initialize w32_crypto_hprov. (w32_init_crypt_random, w32_init_random): New functions. Include wincrypt.h. * src/w32.h (w32_init_random): Add prototype. which indicates that Eli noticed a problem around then. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-21 7:36 ` Paul Eggert @ 2016-03-21 9:22 ` martin rudalics 2016-03-21 17:55 ` Paul Eggert 2016-03-21 16:06 ` Eli Zaretskii 1 sibling, 1 reply; 68+ messages in thread From: martin rudalics @ 2016-03-21 9:22 UTC (permalink / raw) To: Paul Eggert; +Cc: John Wiegley, Eli Zaretskii, emacs-devel [...] > which in turn is a parent of: > > commit 1b76d9168336ede8976b980aeaed64ae2908501a > Merge: bca4930 2e5a89f > Author: John Wiegley <johnw@newartisans.com> > Date: Mon Jan 18 22:59:51 2016 -0800 > > - > > which in turn is a parent of: > > commit b895c72059521fec064ff27b4cfcfa4104081c4e > Merge: badcd38 1b76d91 > Author: Vincent Belaïche <vincentb1@users.sourceforge.net> > Date: Wed Jan 20 08:30:51 2016 +0100 > > Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs > > which leads via a long thin graph to the merge commit > 82b089783e71b2aeef950eaecfe4cbc0735e64a2 that you identified as losing > the change. Thanks for the forensics. I have no idea which tools to use to trace such a path. One thing that stupefies me is that in commit fbce4757a874cc43806eb41b8637538b101c3c69 Author: Alan Mackenzie <acm@muc.de> Date: Sun Jan 24 20:30:39 2016 +0000 which IIUC follows the commits you cited above, the "correct" version is still there why it should have been already lost at least on January 20. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-21 9:22 ` martin rudalics @ 2016-03-21 17:55 ` Paul Eggert 2016-03-22 10:22 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Paul Eggert @ 2016-03-21 17:55 UTC (permalink / raw) To: martin rudalics; +Cc: John Wiegley, Eli Zaretskii, emacs-devel martin rudalics wrote: > Thanks for the forensics. I have no idea which tools to use to trace > such a path. You might try gitk. It's not perfect, but it beats 'git log' for this sort of thing. > One thing that stupefies me is that in > > commit fbce4757a874cc43806eb41b8637538b101c3c69 > Author: Alan Mackenzie <acm@muc.de> > Date: Sun Jan 24 20:30:39 2016 +0000 > > which IIUC follows the commits you cited above, the "correct" version is > still there why it should have been already lost at least on January 20. That patch was applied after the problematic merge e6d575316a42946aac6d83c9587f09afd1a59d98 that propagated the problems I identified in my previous email, so it is immune to those problems. Specifically, the problematic merge combined fef1b3066ae02ec6dd37b0358905491fabbedfdf (which did not have the problem) and 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa (which did have the problem), whereas the commit you cite is an immediate child of fef1b3066ae02ec6dd37b0358905491fabbedfdf and was therefore applied in the next merge (cb4e054e41cdb7e398351a5ae8224759e721349e). ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-21 17:55 ` Paul Eggert @ 2016-03-22 10:22 ` martin rudalics 2016-03-22 10:36 ` Andreas Schwab 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2016-03-22 10:22 UTC (permalink / raw) To: Paul Eggert; +Cc: John Wiegley, Eli Zaretskii, emacs-devel > You might try gitk. It's not perfect, but it beats 'git log' for this > sort of thing. I'm probably too silly but neither with gitk I can visualize the commit that did reset m->total_cols = new_size; to m->total_cols = size; > > One thing that stupefies me is that in >> >> commit fbce4757a874cc43806eb41b8637538b101c3c69 >> Author: Alan Mackenzie <acm@muc.de> >> Date: Sun Jan 24 20:30:39 2016 +0000 >> >> which IIUC follows the commits you cited above, the "correct" version is >> still there why it should have been already lost at least on January 20. > > That patch was applied after the problematic merge > e6d575316a42946aac6d83c9587f09afd1a59d98 that propagated the problems > I identified in my previous email, so it is immune to those problems. > > Specifically, the problematic merge combined > fef1b3066ae02ec6dd37b0358905491fabbedfdf (which did not have the > problem) and 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa (which did have > the problem), whereas the commit you cite is an immediate child of > fef1b3066ae02ec6dd37b0358905491fabbedfdf and was therefore applied in > the next merge (cb4e054e41cdb7e398351a5ae8224759e721349e). I'm still lost. (1) I do C-x v l in master's window.c. (2) I go to the fragment commit fbce4757a874cc43806eb41b8637538b101c3c69 Author: Alan Mackenzie <acm@muc.de> Date: Sun Jan 24 20:30:39 2016 +0000 and on the commit line I type 'f' which gets me a buffer called window.c.~fbce4757a874cc43806eb41b8637538b101c3c69~. Line 4079 of that buffer shows m->total_cols = new_size; Now IIUC this means that this line "was in master once". Or am I wrong? (3) Now I go to the fragment commit 82b089783e71b2aeef950eaecfe4cbc0735e64a2 Merge: d27c807 f7dc6d8 Author: Paul Eggert <eggert@cs.ucla.edu> Date: Sat Jan 30 11:27:34 2016 -0800 and on the commit line I type 'f' which gets me a buffer called window.c.~82b089783e71b2aeef950eaecfe4cbc0735e64a2~. Line 4079 of that buffer shows me m->total_cols = size; Since as you said 82b089783e71b2aeef950eaecfe4cbc0735e64a2 is not the offending commit there must have been a commit (on master) in between the commits I cited above that did reset line 4079. If so, how do I find that offending commit? Apparently "git log src/window.c" won't find it which IIUC renders this command useless for tracking merges. Neither do git show 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa git show cb4e054e41cdb7e398351a5ae8224759e721349e show any changes to window.c. And git show 7823745acbe9b87eea2db4ef434e379fc903ec35 which you cited earlier as the culprit only tells me that commit 7823745acbe9b87eea2db4ef434e379fc903ec35 Merge: 6acd2aa bb0cd31 Author: John Wiegley <johnw@newartisans.com> Date: Mon Jan 18 22:56:33 2016 -0800 ; Merge from origin/emacs-25 The following commit was skipped: bb0cd31 Merge branch 'emacs-25' of git.sv.gnu.org:/srv/git/emacs into emacs-25 So was that line that in (2) above apparently "was in master once" removed silently? martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 10:22 ` martin rudalics @ 2016-03-22 10:36 ` Andreas Schwab 2016-03-22 10:58 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Andreas Schwab @ 2016-03-22 10:36 UTC (permalink / raw) To: martin rudalics; +Cc: John Wiegley, Eli Zaretskii, Paul Eggert, emacs-devel martin rudalics <rudalics@gmx.at> writes: > Neither do > > git show 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa > git show cb4e054e41cdb7e398351a5ae8224759e721349e Try git show -m to see both sides. A diff for a merge commit by default only shows changes that differ from both sides. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 10:36 ` Andreas Schwab @ 2016-03-22 10:58 ` martin rudalics 2016-03-22 11:32 ` Andreas Schwab 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2016-03-22 10:58 UTC (permalink / raw) To: Andreas Schwab; +Cc: John Wiegley, Eli Zaretskii, Paul Eggert, emacs-devel >> Neither do >> >> git show 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa >> git show cb4e054e41cdb7e398351a5ae8224759e721349e > > Try git show -m to see both sides. A diff for a merge commit by default > only shows changes that differ from both sides. Thanks, this seems to show it. But git show -m 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa gets me some 500.000 lines of output. Is there a way to restrict that to src/window.c? martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 10:58 ` martin rudalics @ 2016-03-22 11:32 ` Andreas Schwab 2016-03-22 11:47 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Andreas Schwab @ 2016-03-22 11:32 UTC (permalink / raw) To: martin rudalics; +Cc: John Wiegley, Eli Zaretskii, Paul Eggert, emacs-devel martin rudalics <rudalics@gmx.at> writes: > git show -m 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa > > gets me some 500.000 lines of output. Is there a way to restrict > that to src/window.c? git diff 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa^2 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa -- src/window.c Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 11:32 ` Andreas Schwab @ 2016-03-22 11:47 ` martin rudalics 2016-03-22 15:20 ` Óscar Fuentes 2016-03-22 15:24 ` Noam Postavsky 0 siblings, 2 replies; 68+ messages in thread From: martin rudalics @ 2016-03-22 11:47 UTC (permalink / raw) To: Andreas Schwab; +Cc: John Wiegley, Eli Zaretskii, Paul Eggert, emacs-devel > git diff 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa^2 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa -- src/window.c With git version 1.9.4.msysgit.2 (on Windows) this gets me git diff 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa^2 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa -- src/window.c fatal: bad revision '9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa2' martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 11:47 ` martin rudalics @ 2016-03-22 15:20 ` Óscar Fuentes 2016-03-22 17:08 ` martin rudalics 2016-03-22 15:24 ` Noam Postavsky 1 sibling, 1 reply; 68+ messages in thread From: Óscar Fuentes @ 2016-03-22 15:20 UTC (permalink / raw) To: emacs-devel martin rudalics <rudalics@gmx.at> writes: >> git diff 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa^2 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa -- src/window.c > > With git version 1.9.4.msysgit.2 (on Windows) this gets me > > git diff 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa^2 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa -- src/window.c > fatal: bad revision '9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa2' Most probably that git version is too old to support the ^2 syntax. Please install the latest Git for Windows: https://git-for-windows.github.io/ The output is diff --git a/src/window.c b/src/window.c index 9e065ea..70b7e58 100644 --- a/src/window.c +++ b/src/window.c @@ -3971,11 +3971,9 @@ values. */) } -/* Resize frame F's windows when F's width or height is set to SIZE. - If HORFLAG is zero, F's width was set to SIZE, otherwise its height - was set. SIZE is interpreted in F's canonical character units - (a.k.a. "columns" or "lines"), unless PIXELWISE is non-zero, which - means to interpret SIZE in pixel units. */ +/* Resize frame F's windows when number of lines of F is set to SIZE. + HORFLAG means resize windows when number of columns of F is set to + SIZE. PIXELWISE means to interpret SIZE as pixels. */ void resize_frame_windows (struct frame *f, int size, bool horflag, bool pixelwise) { @@ -4076,7 +4074,7 @@ resize_frame_windows (struct frame *f, int size, bool horflag, bool pixelwise) m = XWINDOW (mini); if (horflag) { - m->total_cols = new_size; + m->total_cols = size; m->pixel_width = new_pixel_size; } else ^ permalink raw reply related [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 15:20 ` Óscar Fuentes @ 2016-03-22 17:08 ` martin rudalics 0 siblings, 0 replies; 68+ messages in thread From: martin rudalics @ 2016-03-22 17:08 UTC (permalink / raw) To: Óscar Fuentes, emacs-devel > Most probably that git version is too old to support the ^2 syntax. That's what I suspected initially but it turned out that I was just too sloppy when reading the error message. > diff --git a/src/window.c b/src/window.c > index 9e065ea..70b7e58 100644 > --- a/src/window.c > +++ b/src/window.c > @@ -3971,11 +3971,9 @@ values. */) > } > > > -/* Resize frame F's windows when F's width or height is set to SIZE. > - If HORFLAG is zero, F's width was set to SIZE, otherwise its height > - was set. SIZE is interpreted in F's canonical character units > - (a.k.a. "columns" or "lines"), unless PIXELWISE is non-zero, which > - means to interpret SIZE in pixel units. */ > +/* Resize frame F's windows when number of lines of F is set to SIZE. > + HORFLAG means resize windows when number of columns of F is set to > + SIZE. PIXELWISE means to interpret SIZE as pixels. */ > void > resize_frame_windows (struct frame *f, int size, bool horflag, bool pixelwise) > { > @@ -4076,7 +4074,7 @@ resize_frame_windows (struct frame *f, int size, bool horflag, bool pixelwise) > m = XWINDOW (mini); > if (horflag) > { > - m->total_cols = new_size; > + m->total_cols = size; > m->pixel_width = new_pixel_size; > } > else > > > Exactly what I was looking for and what I now get here as well ;-) Thanks, martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 11:47 ` martin rudalics 2016-03-22 15:20 ` Óscar Fuentes @ 2016-03-22 15:24 ` Noam Postavsky 2016-03-22 17:08 ` martin rudalics 1 sibling, 1 reply; 68+ messages in thread From: Noam Postavsky @ 2016-03-22 15:24 UTC (permalink / raw) To: martin rudalics Cc: Andreas Schwab, Eli Zaretskii, Paul Eggert, emacs-devel, John Wiegley On Tue, Mar 22, 2016 at 7:47 AM, martin rudalics <rudalics@gmx.at> wrote: >> git diff 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa^2 >> 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa -- src/window.c > > With git version 1.9.4.msysgit.2 (on Windows) this gets me > > git diff 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa^2 > 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa -- src/window.c > fatal: bad revision '9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa2' If you were doing this from a cmd.exe prompt, then ^ is an escape character so you need to enter it twice: git diff 9304...d2c2aa^^2 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 15:24 ` Noam Postavsky @ 2016-03-22 17:08 ` martin rudalics 0 siblings, 0 replies; 68+ messages in thread From: martin rudalics @ 2016-03-22 17:08 UTC (permalink / raw) To: Noam Postavsky Cc: Andreas Schwab, Eli Zaretskii, Paul Eggert, emacs-devel, John Wiegley >> git diff 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa^2 >> 9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa -- src/window.c >> fatal: bad revision '9304e6d3a222de6ef1c405bfd6e09eee6ed2c2aa2' > > If you were doing this from a cmd.exe prompt, then ^ is an escape > character so you need to enter it twice: git diff 9304...d2c2aa^^2 It should have been obvious from the message but I was in a hurry ... Thank you very much for the explanation, martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-21 7:36 ` Paul Eggert 2016-03-21 9:22 ` martin rudalics @ 2016-03-21 16:06 ` Eli Zaretskii 2016-03-21 17:55 ` John Wiegley 1 sibling, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-21 16:06 UTC (permalink / raw) To: Paul Eggert; +Cc: rudalics, johnw, emacs-devel > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, > John Wiegley <johnw@newartisans.com> > From: Paul Eggert <eggert@cs.ucla.edu> > Date: Mon, 21 Mar 2016 00:36:29 -0700 > > commit 64a568d6100e5eab5b86e8bd31846212654d1fcf > Author: Eli Zaretskii <eliz@gnu.org> > Date: Wed Jan 20 11:47:19 2016 +0200 > > Fix MS-Windows build broken by a botched merge from emacs-25 > > * src/w32.c (w32_crypto_hprov): New static variable. > (globals_of_w32): Initialize w32_crypto_hprov. > (w32_init_crypt_random, w32_init_random): New functions. > Include wincrypt.h. > * src/w32.h (w32_init_random): Add prototype. > > > which indicates that Eli noticed a problem around then. I didn't: the compiler did. This omission caused compilation failures, so I looked into that and found the problem. But I didn't try looking for other similar omissions, and even if I'd think about that (which I didn't), I wouldn't know how to do that. Is there some handy set of Git commands to help in this matter? I hope the reason(s) for these problems could be revealed, because otherwise we don't really know what we have on master, code-wise. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-21 16:06 ` Eli Zaretskii @ 2016-03-21 17:55 ` John Wiegley 2016-03-21 17:57 ` Paul Eggert 2016-03-21 18:16 ` Eli Zaretskii 0 siblings, 2 replies; 68+ messages in thread From: John Wiegley @ 2016-03-21 17:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rudalics, Paul Eggert, emacs-devel >>>>> Eli Zaretskii <eliz@gnu.org> writes: > I hope the reason(s) for these problems could be revealed, because otherwise > we don't really know what we have on master, code-wise. The only true way to ever know is: git diff origin/emacs-25 origin/master And then go over it by eye. This is part of the pain of maintaining long lived development forks. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-21 17:55 ` John Wiegley @ 2016-03-21 17:57 ` Paul Eggert 2016-03-21 18:16 ` Eli Zaretskii 1 sibling, 0 replies; 68+ messages in thread From: Paul Eggert @ 2016-03-21 17:57 UTC (permalink / raw) To: Eli Zaretskii, rudalics, emacs-devel John Wiegley wrote: > The only true way to ever know is: > > git diff origin/emacs-25 origin/master > > And then go over it by eye. This is part of the pain of maintaining long lived > development forks. Even if that is done, it's also helpful to find out what caused this specific problem in order to easily find and fix neighboring problems. I'm not sure anybody has the time to do that diff right now. (I don't.) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-21 17:55 ` John Wiegley 2016-03-21 17:57 ` Paul Eggert @ 2016-03-21 18:16 ` Eli Zaretskii 2016-03-21 21:27 ` John Wiegley 1 sibling, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-21 18:16 UTC (permalink / raw) To: John Wiegley; +Cc: rudalics, eggert, emacs-devel > From: John Wiegley <jwiegley@gmail.com> > Cc: Paul Eggert <eggert@cs.ucla.edu>, rudalics@gmx.at, emacs-devel@gnu.org > Date: Mon, 21 Mar 2016 10:55:08 -0700 > > >>>>> Eli Zaretskii <eliz@gnu.org> writes: > > > I hope the reason(s) for these problems could be revealed, because otherwise > > we don't really know what we have on master, code-wise. > > The only true way to ever know is: > > git diff origin/emacs-25 origin/master > > And then go over it by eye. Sorry, I'm not following: the above will just show the diffs between the branches. I asked about the reason(s) for the omission of some commits from the merge. How will "git diff" satisfy that request? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-21 18:16 ` Eli Zaretskii @ 2016-03-21 21:27 ` John Wiegley 2016-03-22 0:17 ` Paul Eggert 2016-03-22 3:35 ` Eli Zaretskii 0 siblings, 2 replies; 68+ messages in thread From: John Wiegley @ 2016-03-21 21:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rudalics, eggert, emacs-devel >>>>> Eli Zaretskii <eliz@gnu.org> writes: > Sorry, I'm not following: the above will just show the diffs between the > branches. I asked about the reason(s) for the omission of some commits from > the merge. How will "git diff" satisfy that request? As for "reason for the omission", I think there are two possible answers: 1. gitmerge.el auto-marked it to be skipped, and despite my examination of each such mark, I failed to see that should not be skipped. 2. I incorrectly resolved a merge conflict that seemed simple enough to me that I didn't e-mail the author of the commit about it. So, in both case, human error pointed at me. If there's a tool error here, I'd be surprised. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-21 21:27 ` John Wiegley @ 2016-03-22 0:17 ` Paul Eggert 2016-03-22 0:52 ` Paul Eggert 2016-03-22 3:35 ` Eli Zaretskii 1 sibling, 1 reply; 68+ messages in thread From: Paul Eggert @ 2016-03-22 0:17 UTC (permalink / raw) To: Eli Zaretskii, rudalics, emacs-devel; +Cc: Phillip Lord [-- Attachment #1: Type: text/plain, Size: 1537 bytes --] On 03/21/2016 02:27 PM, John Wiegley wrote: > I think there are two possible answers: > > 1. gitmerge.el auto-marked it to be skipped, and despite my examination of > each such mark, I failed to see that should not be skipped. > > 2. I incorrectly resolved a merge conflict that seemed simple enough to me > that I didn't e-mail the author of the commit about it. > > So, in both case, human error pointed at me. I think you're right it wasn't a tool error per se (though the tools are error-prone). Human error also points at me, since I merged the resulting bad branch against a good branch and didn't notice the issue. In an attempt to fix the problem I looked for the clump of commits near the lost one, and reinstalled them into master by applying the attached patches. (I did not look for similar clumps yet.) There is one patch near this clump, where I wasn't sure whether it was superseded by existing patches on 'master', so I left it alone. Phillip, can you please look into this? Thanks. The patch in question is this one, and the question is whether it needs to be modified and reapplied to the master branch: commit 549a765efeca2748e68a5c6ce6c9238784e82535 Author: Phillip Lord <phillip.lord@russet.org.uk> Date: Fri Jan 15 22:11:39 2016 +0000 Enable test selector from command line * test/automated/Makefile.in: Change variable manipulation to avoid over-writing selector. http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=549a765efeca2748e68a5c6ce6c9238784e82535 [-- Attachment #2: 0001-etc-NEWS-Remove-unneeded-text.patch --] [-- Type: application/x-patch, Size: 731 bytes --] [-- Attachment #3: 0002-Fix-picture-mode-wrt-double-width-characters.patch --] [-- Type: application/x-patch, Size: 1219 bytes --] [-- Attachment #4: 0003-Unhide-the-no-line-directive-option-to-etags.patch --] [-- Type: application/x-patch, Size: 3023 bytes --] [-- Attachment #5: 0004-Merge-doc-fixes-for-random-lost-in-previous-merge.patch --] [-- Type: application/x-patch, Size: 1807 bytes --] [-- Attachment #6: 0005-In-comment-dwim-with-style-extra-line-respect-indent.patch --] [-- Type: application/x-patch, Size: 1950 bytes --] [-- Attachment #7: 0006-Ensure-positive-number-of-glyphs-for-margins-of-posi.patch --] [-- Type: application/x-patch, Size: 1185 bytes --] [-- Attachment #8: 0007-Don-t-confuse-with-when-trying-to-parse-member-initi.patch --] [-- Type: application/x-patch, Size: 2421 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 0:17 ` Paul Eggert @ 2016-03-22 0:52 ` Paul Eggert 0 siblings, 0 replies; 68+ messages in thread From: Paul Eggert @ 2016-03-22 0:52 UTC (permalink / raw) To: Eli Zaretskii, rudalics, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1424 bytes --] On 03/21/2016 05:17 PM, Paul Eggert wrote: > (I did not look for similar clumps yet.) I looked for similar clumps of errors (i.e., patches lost by incorrect merges to master), and found two as noted below. I suspect gitmerge.el somehow encourages these errors, but haven't looked into how that might be. In the meantime I suggest looking skeptically at anything gitmerge does where the log message looks like "The following commit was skipped: ... Merge branch 'A' ... into B", as skipping a merge ought to be a big deal. I installed the attached patches to attempt to resurrect the two lost master patches. Here are logs for the merges that lost patches: commit 5ab243f40e4db91586ff74b01a775a5218a1d5be Merge: f991a50 52f64cc Author: John Wiegley <johnw@newartisans.com> Date: Thu Mar 3 23:53:26 2016 -0800 ; Merge from origin/emacs-25 The following commit was skipped: 52f64cc Merge branch 'emacs-25' of git.sv.gnu.org:/srv/git/emacs into emacs-25 This lost commit 433407d8230a8a256b26c6c7615d3921b43f59ce. commit c71e7cc113ed0d5f01aaa2e441a3e3c9fbeb9fa5 Merge: f55fc92 1fbcc8a Author: Paul Eggert <eggert@cs.ucla.edu> Date: Tue Feb 9 14:23:10 2016 -0800 ; Merge from origin/emacs-25 The following commit was skipped: 1fbcc8a Merge branch 'emacs-25' of git.savannah.gnu.org:/srv/git/emacs into emacs-25 This lost commit c1d32a65372c72d7de4808d620eefd3214a8e92a. [-- Attachment #2: 0001-etc-TODO-Minor-quoting-and-grammar-fixes.patch --] [-- Type: application/x-patch, Size: 4694 bytes --] [-- Attachment #3: 0002-Fix-problems-caused-by-new-implementation-of-sub-wor.patch --] [-- Type: application/x-patch, Size: 87470 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-21 21:27 ` John Wiegley 2016-03-22 0:17 ` Paul Eggert @ 2016-03-22 3:35 ` Eli Zaretskii 2016-03-22 16:18 ` Eli Zaretskii 1 sibling, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-22 3:35 UTC (permalink / raw) To: John Wiegley; +Cc: rudalics, eggert, emacs-devel > From: John Wiegley <jwiegley@gmail.com> > Cc: eggert@cs.ucla.edu, rudalics@gmx.at, emacs-devel@gnu.org > Date: Mon, 21 Mar 2016 14:27:54 -0700 > > As for "reason for the omission", I think there are two possible answers: > > 1. gitmerge.el auto-marked it to be skipped, and despite my examination of > each such mark, I failed to see that should not be skipped. > > 2. I incorrectly resolved a merge conflict that seemed simple enough to me > that I didn't e-mail the author of the commit about it. But in these cases, the commit we lost should have been mentioned in the list of skipped one. It wasn't, AFAICS. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 3:35 ` Eli Zaretskii @ 2016-03-22 16:18 ` Eli Zaretskii 2016-03-22 16:30 ` Stefan Monnier 2016-03-22 17:00 ` Phillip Lord 0 siblings, 2 replies; 68+ messages in thread From: Eli Zaretskii @ 2016-03-22 16:18 UTC (permalink / raw) To: John Wiegley, rudalics, eggert; +Cc: emacs-devel > Date: Tue, 22 Mar 2016 05:35:32 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: rudalics@gmx.at, eggert@cs.ucla.edu, emacs-devel@gnu.org > > > From: John Wiegley <address@hidden> > > Cc: address@hidden, address@hidden, address@hidden > > Date: Mon, 21 Mar 2016 14:27:54 -0700 > > > > As for "reason for the omission", I think there are two possible answers: > > > > 1. gitmerge.el auto-marked it to be skipped, and despite my examination of > > each such mark, I failed to see that should not be skipped. > > > > 2. I incorrectly resolved a merge conflict that seemed simple enough to me > > that I didn't e-mail the author of the commit about it. > > But in these cases, the commit we lost should have been mentioned in > the list of skipped one. It wasn't, AFAICS. I think I know what happened. It goes like this: . Phillip worked on test selector for the test suite. When he finished, he made a local commit 549a765 on the emacs-25 branch. . Phillip then said "git pull", followed by "git push". This produced the merge-commit bb0cd31, which incorporated 9 other commits that were pushed there since the time Phillip started working on 549a765. One of these 9 commits was my commit that fixed resize_frame_windows. . When John merged all of that to master, bb0cd31 was skipped. Skipping it omitted all the 9 commits that were merged by bb0cd31. So the question (to John) now becomes: why was bb0cd31 skipped? Was that something that gitmerge.el suggested? If so, we should fix gitmerge.el not to make such dangerous proposals in the future. We should also audit all the other commits merged in bb0cd31, and probably also in any other similar merge-commit that was skipped by John in the merge to master. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 16:18 ` Eli Zaretskii @ 2016-03-22 16:30 ` Stefan Monnier 2016-03-22 16:45 ` Eli Zaretskii ` (2 more replies) 2016-03-22 17:00 ` Phillip Lord 1 sibling, 3 replies; 68+ messages in thread From: Stefan Monnier @ 2016-03-22 16:30 UTC (permalink / raw) To: emacs-devel > I think I know what happened. It goes like this: Sounds like a good explanation, thank you. > . Phillip then said "git pull", followed by "git push". That's a problem in itself, since it leads to annoying commit diffs that repeat other things, and it changes "git log" ordering in confusing ways (makes it seem like mainline's development is Philip's and when happened on master during this time was done on a branch). > . When John merged all of that to master, bb0cd31 was skipped. > Skipping it omitted all the 9 commits that were merged by bb0cd31. > So the question (to John) now becomes: why was bb0cd31 skipped? Probably because it's a merge commit, so its commit message contains "merge" which is in bzrmerge-skip-regexp. We should probably remove "merge" from bzrmerge-skip-regexp (and use "backport" as the main magic keyword) or at least refine it to only match things like "don't merge". Stefan ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 16:30 ` Stefan Monnier @ 2016-03-22 16:45 ` Eli Zaretskii 2016-03-22 16:52 ` Stefan Monnier 2016-03-22 18:32 ` Paul Eggert 2016-03-25 8:52 ` Eli Zaretskii 2 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-22 16:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Tue, 22 Mar 2016 12:30:52 -0400 > > > . Phillip then said "git pull", followed by "git push". > > That's a problem in itself, since it leads to annoying commit diffs that > repeat other things, and it changes "git log" ordering in confusing ways > (makes it seem like mainline's development is Philip's and when happened > on master during this time was done on a branch). Indeed. But sometimes this cannot be avoided, because no matter how quick you are, there's always a chance that someone else pushes between your local commit and your push. The probability of this could be brought down significantly by "git pull" before the local commit, but it cannot be eliminated altogether. > > . When John merged all of that to master, bb0cd31 was skipped. > > Skipping it omitted all the 9 commits that were merged by bb0cd31. > > So the question (to John) now becomes: why was bb0cd31 skipped? > > Probably because it's a merge commit, so its commit message contains > "merge" which is in bzrmerge-skip-regexp. We should probably remove > "merge" from bzrmerge-skip-regexp (and use "backport" as the main magic > keyword) or at least refine it to only match things like "don't merge". You mean, gitmerge-skip-regexp. Yes, I think that's the reason. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 16:45 ` Eli Zaretskii @ 2016-03-22 16:52 ` Stefan Monnier 2016-03-22 17:03 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: Stefan Monnier @ 2016-03-22 16:52 UTC (permalink / raw) To: emacs-devel >> > . Phillip then said "git pull", followed by "git push". >> That's a problem in itself, since it leads to annoying commit diffs that >> repeat other things, and it changes "git log" ordering in confusing ways >> (makes it seem like mainline's development is Philip's and when happened >> on master during this time was done on a branch). > Indeed. But sometimes this cannot be avoided, because no matter how > quick you are, there's always a chance that someone else pushes > between your local commit and your push. The probability of this > could be brought down significantly by "git pull" before the local > commit, but it cannot be eliminated altogether. "git rebase" should do the trick. Stefan ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 16:52 ` Stefan Monnier @ 2016-03-22 17:03 ` Eli Zaretskii 2016-03-22 18:21 ` Paul Eggert ` (2 more replies) 0 siblings, 3 replies; 68+ messages in thread From: Eli Zaretskii @ 2016-03-22 17:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Tue, 22 Mar 2016 12:52:48 -0400 > > >> > . Phillip then said "git pull", followed by "git push". > >> That's a problem in itself, since it leads to annoying commit diffs that > >> repeat other things, and it changes "git log" ordering in confusing ways > >> (makes it seem like mainline's development is Philip's and when happened > >> on master during this time was done on a branch). > > Indeed. But sometimes this cannot be avoided, because no matter how > > quick you are, there's always a chance that someone else pushes > > between your local commit and your push. The probability of this > > could be brought down significantly by "git pull" before the local > > commit, but it cannot be eliminated altogether. > > "git rebase" should do the trick. We've been through this: "git rebase" will cause much worse trouble if you have local merge-commits from feature branches. So I at least will never use "git rebase" unless I have no other choice. When we started using Git, I explicitly asked whether we cared about the messed-up DAG due to these merge-commits, and the answer was "we don't". So I never looked back, and I guess others didn't, too. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 17:03 ` Eli Zaretskii @ 2016-03-22 18:21 ` Paul Eggert 2016-03-22 18:33 ` Eli Zaretskii 2016-03-22 18:41 ` Stefan Monnier 2016-03-22 19:34 ` Lars Magne Ingebrigtsen 2 siblings, 1 reply; 68+ messages in thread From: Paul Eggert @ 2016-03-22 18:21 UTC (permalink / raw) To: Eli Zaretskii, Stefan Monnier; +Cc: emacs-devel On 03/22/2016 10:03 AM, Eli Zaretskii wrote: >> "git rebase" should do the trick. > We've been through this: "git rebase" will cause much worse trouble if > you have local merge-commits from feature branches. So I at least > will never use "git rebase" unless I have no other choice. For complex clashes such as the one you describe, you might try redoing the failed push from a clean new master branch rather than attempting "git pull / git push". Something like this: $ git push [ fails due to somebody else committing in the meantime ] $ git branch -m master master-clashed $ git branch --track master origin/master $ git checkout master $ git pull [ now, merge your changes again ] $ git push ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 18:21 ` Paul Eggert @ 2016-03-22 18:33 ` Eli Zaretskii 2016-03-23 13:10 ` Stefan Monnier 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-22 18:33 UTC (permalink / raw) To: Paul Eggert; +Cc: monnier, emacs-devel > Cc: emacs-devel@gnu.org > From: Paul Eggert <eggert@cs.ucla.edu> > Date: Tue, 22 Mar 2016 11:21:04 -0700 > > On 03/22/2016 10:03 AM, Eli Zaretskii wrote: > >> "git rebase" should do the trick. > > We've been through this: "git rebase" will cause much worse trouble if > > you have local merge-commits from feature branches. So I at least > > will never use "git rebase" unless I have no other choice. > > For complex clashes such as the one you describe, you might try redoing > the failed push from a clean new master branch rather than attempting > "git pull / git push". Something like this: > > $ git push > [ fails due to somebody else committing in the meantime ] > $ git branch -m master master-clashed > $ git branch --track master origin/master > $ git checkout master > $ git pull > [ now, merge your changes again ] > $ git push Thanks, but I don't see why I should bother with such complications, when no one cares about the DAG keeping a clear "mainline". ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 18:33 ` Eli Zaretskii @ 2016-03-23 13:10 ` Stefan Monnier 0 siblings, 0 replies; 68+ messages in thread From: Stefan Monnier @ 2016-03-23 13:10 UTC (permalink / raw) To: emacs-devel > Thanks, but I don't see why I should bother with such complications, > when no one cares about the DAG keeping a clear "mainline". Agreed. If we want that, we should setup some post-receive-hook which enforces it. Stefan ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 17:03 ` Eli Zaretskii 2016-03-22 18:21 ` Paul Eggert @ 2016-03-22 18:41 ` Stefan Monnier 2016-03-22 18:58 ` Eli Zaretskii 2016-03-22 19:34 ` Lars Magne Ingebrigtsen 2 siblings, 1 reply; 68+ messages in thread From: Stefan Monnier @ 2016-03-22 18:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel > We've been through this: "git rebase" will cause much worse trouble if > you have local merge-commits from feature branches. Indeed. The problem is very real when you want to do "git merge; git push" and the merge is non-trivial, since you have to hurry to fix the merge problems before someone else. > So I at least will never use "git rebase" unless I have no > other choice. I do use "git rebase" when none of the local commits are merges. When there's a merge, the only option I know of is to checkout "master", then do a "git merge {localbranch}; git push". I really think there should be a way to tell git to "merge in the other direction", but Git people don't seem to listen. > When we started using Git, I explicitly asked whether we cared about > the messed-up DAG due to these merge-commits, and the answer was "we > don't". So I never looked back, and I guess others didn't, too. What can I say, you were right. I'm not really bothered by the shape of the DAG itself, but the commit-diffs are pretty annoying and there are a few other linked problems such as the one discussed in this thread. Stefan ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 18:41 ` Stefan Monnier @ 2016-03-22 18:58 ` Eli Zaretskii 2016-03-23 2:08 ` Stefan Monnier 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-22 18:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: emacs-devel@gnu.org > Date: Tue, 22 Mar 2016 14:41:53 -0400 > > > When we started using Git, I explicitly asked whether we cared about > > the messed-up DAG due to these merge-commits, and the answer was "we > > don't". So I never looked back, and I guess others didn't, too. > > What can I say, you were right. I'm not really bothered by the shape of > the DAG itself, but the commit-diffs are pretty annoying and there are > a few other linked problems such as the one discussed in this thread. I simply don't see how this can be fixed satisfactorily until Git acquires some features to support such a workflow. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 18:58 ` Eli Zaretskii @ 2016-03-23 2:08 ` Stefan Monnier 2016-03-23 8:07 ` Andreas Schwab 0 siblings, 1 reply; 68+ messages in thread From: Stefan Monnier @ 2016-03-23 2:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel > I simply don't see how this can be fixed satisfactorily until Git > acquires some features to support such a workflow. Indeed, although I can't believe those features would have to be complex. A simple "git merge --reverse-parents" should be more or less all it takes. Stefan ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-23 2:08 ` Stefan Monnier @ 2016-03-23 8:07 ` Andreas Schwab 0 siblings, 0 replies; 68+ messages in thread From: Andreas Schwab @ 2016-03-23 8:07 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > A simple "git merge --reverse-parents" should be more or less all it > takes. Send patches. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 17:03 ` Eli Zaretskii 2016-03-22 18:21 ` Paul Eggert 2016-03-22 18:41 ` Stefan Monnier @ 2016-03-22 19:34 ` Lars Magne Ingebrigtsen 2016-03-22 19:49 ` Eli Zaretskii 2016-03-24 7:18 ` Phillip Lord 2 siblings, 2 replies; 68+ messages in thread From: Lars Magne Ingebrigtsen @ 2016-03-22 19:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Stefan Monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > We've been through this: "git rebase" will cause much worse trouble if > you have local merge-commits from feature branches. That's true, but that's a quite unusual thing to be doing. ("Unusual" as in "most of the time most of the people who work on Emacs won't be doing that".) In this instance, if he had done "git pull --rebase; git push" then no merge commit would have been pushed, and things would generally be less confusing. That rebase/push thing is what I do 99.9% of the time, and its the least noisy you can be when doing normal stuff. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 19:34 ` Lars Magne Ingebrigtsen @ 2016-03-22 19:49 ` Eli Zaretskii 2016-03-24 7:18 ` Phillip Lord 1 sibling, 0 replies; 68+ messages in thread From: Eli Zaretskii @ 2016-03-22 19:49 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: monnier, emacs-devel > From: Lars Magne Ingebrigtsen <larsi@gnus.org> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org > Date: Tue, 22 Mar 2016 20:34:52 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > We've been through this: "git rebase" will cause much worse trouble if > > you have local merge-commits from feature branches. > > That's true, but that's a quite unusual thing to be doing. ("Unusual" > as in "most of the time most of the people who work on Emacs won't be > doing that".) I was explaining why _I_ don't want to use rebase when pulling from upstream. To understand that, you need to ask what _I_ do most of the time, not what others do. For me, working on a feature branch is entirely not unusual. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 19:34 ` Lars Magne Ingebrigtsen 2016-03-22 19:49 ` Eli Zaretskii @ 2016-03-24 7:18 ` Phillip Lord 1 sibling, 0 replies; 68+ messages in thread From: Phillip Lord @ 2016-03-24 7:18 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Eli Zaretskii <eliz@gnu.org> writes: > >> We've been through this: "git rebase" will cause much worse trouble if >> you have local merge-commits from feature branches. > > That's true, but that's a quite unusual thing to be doing. ("Unusual" > as in "most of the time most of the people who work on Emacs won't be > doing that".) In this instance, if he had done > "git pull --rebase; git push" then no merge commit would have been > pushed, and things would generally be less confusing. > > That rebase/push thing is what I do 99.9% of the time, and its the least > noisy you can be when doing normal stuff. If I remember correctly, I think I did the commit, but forgot to push, till the next day. Once I got into the merge commit, my lack of git expertise meant I couldn't work out how to get out of it again. Mostly I develop with feature branches, so don't normally get this problem. Ah well, live and learn. Phil ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 16:30 ` Stefan Monnier 2016-03-22 16:45 ` Eli Zaretskii @ 2016-03-22 18:32 ` Paul Eggert 2016-03-22 18:37 ` Eli Zaretskii 2016-03-22 22:57 ` David Engster 2016-03-25 8:52 ` Eli Zaretskii 2 siblings, 2 replies; 68+ messages in thread From: Paul Eggert @ 2016-03-22 18:32 UTC (permalink / raw) To: Stefan Monnier, emacs-devel On 03/22/2016 09:30 AM, Stefan Monnier wrote: > We should probably remove > "merge" from bzrmerge-skip-regexp (and use "backport" as the main magic > keyword) or at least refine it to only match things like "don't merge". I tried gitmerge.el unchanged, found a similar bug with the proposed merge, removed "merge" from gitmerge-skip-regexp, redid the merge and found that it worked better this time, and committed the result into the master. The whole gitmerge.el business is still odd, though. What's up with merge commits like f95bbe5a67e03fe6d05cbfb4d0c9151a754d6ccd whose commit message is merely "-"? Plus, ChangeLog generation is still broken in master. I'm becoming more inclined to install into master the patch I proposed in <http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg00391.html>. Although this patch is merely a stopgap measure until someone figures out a better way to edit commit messages, it's clearly better than what we have now in 'master'. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 18:32 ` Paul Eggert @ 2016-03-22 18:37 ` Eli Zaretskii 2016-03-22 19:15 ` Paul Eggert 2016-03-22 22:57 ` David Engster 1 sibling, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-22 18:37 UTC (permalink / raw) To: Paul Eggert; +Cc: monnier, emacs-devel > From: Paul Eggert <eggert@cs.ucla.edu> > Date: Tue, 22 Mar 2016 11:32:12 -0700 > > Plus, ChangeLog generation is still broken in master. I'm becoming more > inclined to install into master the patch I proposed in > <http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg00391.html>. No, please don't. I don't want us to start fixing mistakes in Perl, because this will just bring more mistakes. John said he wanted to look into this issue, so let's wait. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 18:37 ` Eli Zaretskii @ 2016-03-22 19:15 ` Paul Eggert 2016-03-22 19:42 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: Paul Eggert @ 2016-03-22 19:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 357 bytes --] On 03/22/2016 11:37 AM, Eli Zaretskii wrote: > I don't want us to start fixing mistakes in Perl OK, I can install the attached instead. It won't fix mistakes in Perl, and it will still be better than what we have now (where ChangeLog.2 is plainly bogus in the 'master' branch). It's intended as a stopgap measure until we come up with something better. [-- Attachment #2: 0001-Simplify-autogeneration-of-top-level-ChangeLog.patch --] [-- Type: application/x-patch, Size: 8864 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 19:15 ` Paul Eggert @ 2016-03-22 19:42 ` Eli Zaretskii 2016-03-22 20:26 ` Paul Eggert 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-22 19:42 UTC (permalink / raw) To: Paul Eggert; +Cc: monnier, emacs-devel > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Paul Eggert <eggert@cs.ucla.edu> > Date: Tue, 22 Mar 2016 12:15:00 -0700 > > On 03/22/2016 11:37 AM, Eli Zaretskii wrote: > > I don't want us to start fixing mistakes in Perl > > OK, I can install the attached instead. It won't fix mistakes in Perl, > and it will still be better than what we have now (where ChangeLog.2 is > plainly bogus in the 'master' branch). It's intended as a stopgap > measure until we come up with something better. Isn't it easier and simpler just to delete ChangeLog.2 from the master branch, and leave everything else intact? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 19:42 ` Eli Zaretskii @ 2016-03-22 20:26 ` Paul Eggert 0 siblings, 0 replies; 68+ messages in thread From: Paul Eggert @ 2016-03-22 20:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel On 03/22/2016 12:42 PM, Eli Zaretskii wrote: >> OK, I can install the attached instead. It won't fix mistakes in >> Perl, and it will still be better than what we have now (where >> ChangeLog.2 is plainly bogus in the 'master' branch). It's intended >> as a stopgap measure until we come up with something better. > Isn't it easier and simpler just to delete ChangeLog.2 from the master > branch, and leave everything else intact? No, as that would erase the relevant emacs-25 history from the master branch. Also, it would leave intact the procedure for updating ChangeLog.2 in the master branch, even though we should not be using that procedure there as things stand, and Murphy's law would apply if we left it in there (someone would go ahead and use the procedure anyway). ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 18:32 ` Paul Eggert 2016-03-22 18:37 ` Eli Zaretskii @ 2016-03-22 22:57 ` David Engster 2016-03-22 23:45 ` Paul Eggert 1 sibling, 1 reply; 68+ messages in thread From: David Engster @ 2016-03-22 22:57 UTC (permalink / raw) To: Paul Eggert; +Cc: Stefan Monnier, emacs-devel Paul Eggert writes: > The whole gitmerge.el business is still odd, though. What's up with > merge commits like f95bbe5a67e03fe6d05cbfb4d0c9151a754d6ccd whose > commit message is merely "-"? It's always good to look at the merge before pushing. Anyway, this is because of de8837599112: ;; FIXME: We add "-m-" because the default commit message ;; apparently tickles our commit hook: ;; Line longer than 78 characters in commit message ;; Line longer than 78 characters in commit message ;; Line longer than 78 characters in commit message ;; Commit aborted; please see the file CONTRIBUTE I don't understand this. It only applies to resumed merges, whereas this problem should happen with regular merges as well. And why not simply fix this in `gitmerge-commit-message' through truncation, instead of using a '-' as commit message? -David ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 22:57 ` David Engster @ 2016-03-22 23:45 ` Paul Eggert 0 siblings, 0 replies; 68+ messages in thread From: Paul Eggert @ 2016-03-22 23:45 UTC (permalink / raw) To: David Engster; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 230 bytes --] On 03/22/2016 03:57 PM, David Engster wrote: > why not simply > fix this in `gitmerge-commit-message' through truncation, instead of > using a '-' as commit message? Thanks, good suggestion. I installed the attached into master. [-- Attachment #2: 0001-Compute-a-better-commit-message-for-merges.txt --] [-- Type: text/plain, Size: 2026 bytes --] From 8c25e016ee06b2c2246986690af7ba779b9f0af8 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Tue, 22 Mar 2016 16:42:28 -0700 Subject: [PATCH] Compute a better commit message for merges MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by David Engster in: http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01270.html * admin/gitmerge.el (gitmerge-commit-message): Truncate the computed commit message to at most 72 characters per line. (gitmerge-maybe-resume): Don’t use "-" as the commit message for merges; use the computed commit message instead. --- admin/gitmerge.el | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/admin/gitmerge.el b/admin/gitmerge.el index 74e6f80..6a52f7a 100644 --- a/admin/gitmerge.el +++ b/admin/gitmerge.el @@ -331,6 +331,10 @@ gitmerge-commit-message (if end (list (concat beg "~.." end)) `("-1" ,beg))) (insert "\n") + ;; Truncate to 72 chars so that the resulting ChangeLog line fits in 80. + (goto-char (point-min)) + (while (re-search-forward "^\\(.\\{69\\}\\).\\{4,\\}" nil t) + (replace-match "\\1...")) (buffer-string))) (defun gitmerge-apply (missing from) @@ -432,14 +436,8 @@ gitmerge-maybe-resume (when mergehead (with-current-buffer (get-buffer-create gitmerge-output-buffer) (erase-buffer) - ;; FIXME: We add "-m-" because the default commit message - ;; apparently tickles our commit hook: - ;; Line longer than 78 characters in commit message - ;; Line longer than 78 characters in commit message - ;; Line longer than 78 characters in commit message - ;; Commit aborted; please see the file CONTRIBUTE (unless (zerop (call-process "git" nil t nil - "commit" "--no-edit" "-m-")) + "commit" "--no-edit")) (error "Git error during merge - fix it manually")))) ;; Successfully resumed. t)))) -- 2.5.5 ^ permalink raw reply related [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 16:30 ` Stefan Monnier 2016-03-22 16:45 ` Eli Zaretskii 2016-03-22 18:32 ` Paul Eggert @ 2016-03-25 8:52 ` Eli Zaretskii 2016-03-25 9:14 ` Andreas Schwab 2016-03-25 9:15 ` David Engster 2 siblings, 2 replies; 68+ messages in thread From: Eli Zaretskii @ 2016-03-25 8:52 UTC (permalink / raw) To: John Wiegley; +Cc: emacs-devel There seems to be another issue with merging to master: we get back commits that were cherry-picked from master to the release branch. Here's one example; I don't know whether there are others: commit ad879b7f7e049160c45361fe8a12580801ba035b Author: K. Handa <handa@gnu.org> Date: Thu Jan 14 21:48:44 2016 +0900 Backport:fix previous change of src/ftfont.c (ftfont_shape_by_flt) * src/ftfont.c (ftfont_shape_by_flt): Fix previous change. Access the second glyph only when there are enough glyphs. (cherry picked from commit 9835757013569673854b692ccbb58bfb3c3ed1f7) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 8:52 ` Eli Zaretskii @ 2016-03-25 9:14 ` Andreas Schwab 2016-03-25 10:48 ` Eli Zaretskii 2016-03-25 9:15 ` David Engster 1 sibling, 1 reply; 68+ messages in thread From: Andreas Schwab @ 2016-03-25 9:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: John Wiegley, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > There seems to be another issue with merging to master: we get back > commits that were cherry-picked from master to the release branch. What do you mean with "get back"? Since they are part of the history of the branch and merging incorporates the whole history you will of course see them from master. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 9:14 ` Andreas Schwab @ 2016-03-25 10:48 ` Eli Zaretskii 2016-03-25 11:50 ` Andreas Schwab 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-25 10:48 UTC (permalink / raw) To: Andreas Schwab; +Cc: johnw, emacs-devel > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: John Wiegley <johnw@gnu.org>, emacs-devel@gnu.org > Date: Fri, 25 Mar 2016 10:14:10 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > There seems to be another issue with merging to master: we get back > > commits that were cherry-picked from master to the release branch. > > What do you mean with "get back"? Since they are part of the history of > the branch and merging incorporates the whole history you will of course > see them from master. They were supposed to be skipped during merging, so if what we have currently is the expected result, then what exactly does "skip" mean in this context? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 10:48 ` Eli Zaretskii @ 2016-03-25 11:50 ` Andreas Schwab 2016-03-25 13:55 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: Andreas Schwab @ 2016-03-25 11:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: johnw, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > They were supposed to be skipped during merging They cannot be "skipped". Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 11:50 ` Andreas Schwab @ 2016-03-25 13:55 ` Eli Zaretskii 0 siblings, 0 replies; 68+ messages in thread From: Eli Zaretskii @ 2016-03-25 13:55 UTC (permalink / raw) To: Andreas Schwab; +Cc: johnw, emacs-devel > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: johnw@gnu.org, emacs-devel@gnu.org > Date: Fri, 25 Mar 2016 12:50:00 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > They were supposed to be skipped during merging > > They cannot be "skipped". Maybe I'm naïve, but I hoped for a more informative and helpful answer. I think the problem is real. Maybe I'm mistaken, but with such responses I will never know. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 8:52 ` Eli Zaretskii 2016-03-25 9:14 ` Andreas Schwab @ 2016-03-25 9:15 ` David Engster 2016-03-25 10:50 ` Eli Zaretskii 1 sibling, 1 reply; 68+ messages in thread From: David Engster @ 2016-03-25 9:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: John Wiegley, emacs-devel Eli Zaretskii writes: > There seems to be another issue with merging to master: we get back > commits that were cherry-picked from master to the release branch. When you merge a branch, you have to merge all of it. But when they are marked as 'skipped', they will be merged with strategy "ours", effectively ignoring their content. This is how it worked with Bazaar as well. -David ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 9:15 ` David Engster @ 2016-03-25 10:50 ` Eli Zaretskii 2016-03-25 11:38 ` David Engster 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-25 10:50 UTC (permalink / raw) To: David Engster; +Cc: johnw, emacs-devel > From: David Engster <deng@randomsample.de> > Cc: John Wiegley <johnw@gnu.org>, emacs-devel@gnu.org > Date: Fri, 25 Mar 2016 10:15:41 +0100 > > Eli Zaretskii writes: > > There seems to be another issue with merging to master: we get back > > commits that were cherry-picked from master to the release branch. > > When you merge a branch, you have to merge all of it. But when they are > marked as 'skipped', they will be merged with strategy "ours", > effectively ignoring their content. What does "their content" include, exactly? > This is how it worked with Bazaar as well. With Bazaar, there was a clear mainline, displaying which these commits wouldn't appear at all. We don't have that with Git, so the analogy doesn't really help. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 10:50 ` Eli Zaretskii @ 2016-03-25 11:38 ` David Engster 2016-03-25 14:15 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: David Engster @ 2016-03-25 11:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: johnw, emacs-devel Eli Zaretskii writes: >> From: David Engster <deng@randomsample.de> >> Cc: John Wiegley <johnw@gnu.org>, emacs-devel@gnu.org >> Date: Fri, 25 Mar 2016 10:15:41 +0100 > >> >> Eli Zaretskii writes: >> > There seems to be another issue with merging to master: we get back >> > commits that were cherry-picked from master to the release branch. >> >> When you merge a branch, you have to merge all of it. But when they are >> marked as 'skipped', they will be merged with strategy "ours", >> effectively ignoring their content. > > What does "their content" include, exactly? The patch. The merge-strategy "ours" means: merge the commit, but take "our" version of everything that would be changed by it. The commit is seen as merged afterwards, but without applying the patch it includes. >> This is how it worked with Bazaar as well. > > With Bazaar, there was a clear mainline, displaying which these > commits wouldn't appear at all. We don't have that with Git, so the > analogy doesn't really help. Bazaar didn't display *any* commits from merged branches by default, whether they were "skipped" or not. So again: gitmerge does that same as bzrmerge did. That we don't invest the effort to keep our mainline on the "left side" is another matter. -David ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 11:38 ` David Engster @ 2016-03-25 14:15 ` Eli Zaretskii 2016-03-25 16:00 ` David Engster 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-25 14:15 UTC (permalink / raw) To: David Engster; +Cc: johnw, emacs-devel > From: David Engster <deng@randomsample.de> > Cc: johnw@gnu.org, emacs-devel@gnu.org > Date: Fri, 25 Mar 2016 12:38:15 +0100 > > >> When you merge a branch, you have to merge all of it. But when they are > >> marked as 'skipped', they will be merged with strategy "ours", > >> effectively ignoring their content. > > > > What does "their content" include, exactly? > > The patch. > > The merge-strategy "ours" means: merge the commit, but take "our" > version of everything that would be changed by it. The commit is seen as > merged afterwards, but without applying the patch it includes. I'm not sure I understand the meaning of this. Let me ask a more specific question, about the particular commit that bothers me. Once again, it is this commit from the emacs-25 branch: commit ad879b7f7e049160c45361fe8a12580801ba035b Author: K. Handa <handa@gnu.org> Date: Thu Jan 14 21:48:44 2016 +0900 Backport:fix previous change of src/ftfont.c (ftfont_shape_by_flt) * src/ftfont.c (ftfont_shape_by_flt): Fix previous change. Access the second glyph only when there are enough glyphs. (cherry picked from commit 9835757013569673854b692ccbb58bfb3c3ed1f7) It was originally made on master, as 9835757, then cherry-picked to emacs-25 as above and committed there as ad879b, and then merged back to master in 3005605, with this log message: commit 3005605776955593e0b416de9e1ebf158114343e Merge: cb4e054 ad879b7 Author: Paul Eggert <eggert@cs.ucla.edu> Date: Sat Jan 30 11:43:27 2016 -0800 ; Merge from origin/emacs-25 The following commits were skipped: ad879b7 Backport:fix previous change of src/ftfont.c (ftfont_shape_by_flt) 4a3db0f support rendering of wider range of combinging characters by ftfont After all this, what would you expect "git annotate" to show on the master branch as the commit that introduced the affected source lines? Shouldn't it show the original commit, i.e. 9835757? Because it doesn't show that, it shows ad879b7 instead. If that's expected behavior, then I _really_ don't understand what "skip" means here, since it sounds like it didn't use the "ours" strategy, according to your definition. What am I missing? > > With Bazaar, there was a clear mainline, displaying which these > > commits wouldn't appear at all. We don't have that with Git, so the > > analogy doesn't really help. > > Bazaar didn't display *any* commits from merged branches by default, > whether they were "skipped" or not. Of course: those commits were on other branches, so they are irrelevant for the mainline. What Bazaar would show is the single merge-commit, which (with Bazaar) "represents" the commits on the merged branch. > So again: gitmerge does that same as bzrmerge did. That we don't > invest the effort to keep our mainline on the "left side" is another > matter. I didn't yet voice any complaints about what gitmerge does, I'm just saying that something seems wrong in the DAG. Whether it was gitmerge that produced that remains to be seen; for now, we cannot even agree on what we actually see there, and whether it constitutes a problem ;-) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 14:15 ` Eli Zaretskii @ 2016-03-25 16:00 ` David Engster 2016-03-25 16:27 ` David Engster 2016-03-25 17:33 ` Eli Zaretskii 0 siblings, 2 replies; 68+ messages in thread From: David Engster @ 2016-03-25 16:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: johnw, emacs-devel Eli Zaretskii writes: >> From: David Engster <deng@randomsample.de> >> Cc: johnw@gnu.org, emacs-devel@gnu.org >> Date: Fri, 25 Mar 2016 12:38:15 +0100 > >> >> >> When you merge a branch, you have to merge all of it. But when they are >> >> marked as 'skipped', they will be merged with strategy "ours", >> >> effectively ignoring their content. >> > >> > What does "their content" include, exactly? >> >> The patch. >> >> The merge-strategy "ours" means: merge the commit, but take "our" >> version of everything that would be changed by it. The commit is seen as >> merged afterwards, but without applying the patch it includes. > > I'm not sure I understand the meaning of this. Let me ask a more > specific question, about the particular commit that bothers me. Once > again, it is this commit from the emacs-25 branch: [...] > After all this, what would you expect "git annotate" to show on the > master branch as the commit that introduced the affected source lines? > Shouldn't it show the original commit, i.e. 9835757? Because it > doesn't show that, it shows ad879b7 instead. If that's expected > behavior, then I _really_ don't understand what "skip" means here, > since it sounds like it didn't use the "ours" strategy, according to > your definition. What am I missing? Well, the cherry-picked commit ad879b7 is now in master's history. The patch of that diff shows that it changes those lines. That we chose to ignore the patch can only be seen by looking at the merge commit 300560577, which references the same 'tree' as the previous merge 'cb4e054e', meaning they both reference they same set of files: > git cat-file 300560577 -p tree ae2bec4f10425bd61e2a90563edc178d382bb4b8 [...] > git cat-file cb4e054e41c -p tree ae2bec4f10425bd61e2a90563edc178d382bb4b8 My best guess is that 'git annotate' does not incorporate that information, but I'm not familiar with the inner workings of that command. Maybe no one bothered to implement it, or maybe it would make annotation even slower. As you well know, Bazaar had a data model which was much more amenable for annotating a file, so I guess it could deal with this issue correctly (I haven't checked, though). >> > With Bazaar, there was a clear mainline, displaying which these >> > commits wouldn't appear at all. We don't have that with Git, so the >> > analogy doesn't really help. >> >> Bazaar didn't display *any* commits from merged branches by default, >> whether they were "skipped" or not. > > Of course: those commits were on other branches, so they are > irrelevant for the mainline. Those commits were made part of mainline's history, so how can they possibly be "irrelevant"? It's just that Bazaar had the default to only show mainline (which also confused plenty of people). > What Bazaar would show is the single merge-commit, which (with Bazaar) > "represents" the commits on the merged branch. I forgot how it worked in Bazaar. Did a merge commit hold the full patch information of all merged commits? In any case, that's now the case for Git: a merge commit is a normal commit, simply with more than one parent. >> So again: gitmerge does that same as bzrmerge did. That we don't >> invest the effort to keep our mainline on the "left side" is another >> matter. > > I didn't yet voice any complaints about what gitmerge does, I'm just > saying that something seems wrong in the DAG. Whether it was gitmerge > that produced that remains to be seen; for now, we cannot even agree > on what we actually see there, and whether it constitutes a problem ;-) I can at least assure you that the patches from those commits are ignored. And I would claim that it worked essentially the same during the Bazaar days. Just fire up 'gitk' and look at old merges from emacs-24 into master; you'll find plenty of backported commits in the merged branches, and bzrmerge dealt with it the same way (with the exception that it did the whole merge in one go, while gitmerge does separate merges). -David ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 16:00 ` David Engster @ 2016-03-25 16:27 ` David Engster 2016-03-25 17:33 ` Eli Zaretskii 1 sibling, 0 replies; 68+ messages in thread From: David Engster @ 2016-03-25 16:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: johnw, emacs-devel My proofreader is on holiday... David Engster writes: > Well, the cherry-picked commit ad879b7 is now in master's history. The > patch of that diff shows that it changes those lines. ^^^^ commit [...] > I forgot how it worked in Bazaar. Did a merge commit hold the full patch > information of all merged commits? In any case, that's now the case for ^^^ not > Git: a merge commit is a normal commit, simply with more than one > parent. -David ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 16:00 ` David Engster 2016-03-25 16:27 ` David Engster @ 2016-03-25 17:33 ` Eli Zaretskii 2016-03-25 17:52 ` David Engster ` (2 more replies) 1 sibling, 3 replies; 68+ messages in thread From: Eli Zaretskii @ 2016-03-25 17:33 UTC (permalink / raw) To: David Engster; +Cc: johnw, emacs-devel > From: David Engster <deng@randomsample.de> > Cc: johnw@gnu.org, emacs-devel@gnu.org > Date: Fri, 25 Mar 2016 17:00:45 +0100 > > > After all this, what would you expect "git annotate" to show on the > > master branch as the commit that introduced the affected source lines? > > Shouldn't it show the original commit, i.e. 9835757? Because it > > doesn't show that, it shows ad879b7 instead. If that's expected > > behavior, then I _really_ don't understand what "skip" means here, > > since it sounds like it didn't use the "ours" strategy, according to > > your definition. What am I missing? > > Well, the cherry-picked commit ad879b7 is now in master's history. The > patch of that diff shows that it changes those lines. That we chose to > ignore the patch can only be seen by looking at the merge commit > 300560577, which references the same 'tree' as the previous merge > 'cb4e054e', meaning they both reference they same set of files: > > > git cat-file 300560577 -p > tree ae2bec4f10425bd61e2a90563edc178d382bb4b8 > [...] > > > git cat-file cb4e054e41c -p > tree ae2bec4f10425bd61e2a90563edc178d382bb4b8 > > My best guess is that 'git annotate' does not incorporate that > information, but I'm not familiar with the inner workings of that > command. Maybe no one bothered to implement it, or maybe it would make > annotation even slower. So I guess the fact that a commit was skipped during a merge is something that is so hard to see that perhaps the entire issue of skipping is moot with Git, and we shouldn't be bothered by it. > >> > With Bazaar, there was a clear mainline, displaying which these > >> > commits wouldn't appear at all. We don't have that with Git, so the > >> > analogy doesn't really help. > >> > >> Bazaar didn't display *any* commits from merged branches by default, > >> whether they were "skipped" or not. > > > > Of course: those commits were on other branches, so they are > > irrelevant for the mainline. > > Those commits were made part of mainline's history Not in Bazaar's philosophy. They are part of the DAG, but not of the branch's mainline. > > What Bazaar would show is the single merge-commit, which (with Bazaar) > > "represents" the commits on the merged branch. > > I forgot how it worked in Bazaar. Did a merge commit hold the full patch > information of all merged commits? Yes. > I can at least assure you that the patches from those commits are > ignored. I believe you. It's just strange and confusing that so many Git commands show information that indicates the opposite, and the truth is only shown by looking at the low-level objects and comparing hashes. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 17:33 ` Eli Zaretskii @ 2016-03-25 17:52 ` David Engster 2016-03-25 18:43 ` Eli Zaretskii 2016-03-25 19:42 ` Paul Eggert 2016-03-26 21:34 ` Stefan Monnier 2 siblings, 1 reply; 68+ messages in thread From: David Engster @ 2016-03-25 17:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: johnw, emacs-devel Eli Zaretskii writes: >> From: David Engster <deng@randomsample.de> >> Cc: johnw@gnu.org, emacs-devel@gnu.org >> Date: Fri, 25 Mar 2016 17:00:45 +0100 > >> >> > After all this, what would you expect "git annotate" to show on the >> > master branch as the commit that introduced the affected source lines? >> > Shouldn't it show the original commit, i.e. 9835757? Because it >> > doesn't show that, it shows ad879b7 instead. If that's expected >> > behavior, then I _really_ don't understand what "skip" means here, >> > since it sounds like it didn't use the "ours" strategy, according to >> > your definition. What am I missing? >> >> Well, the cherry-picked commit ad879b7 is now in master's history. The >> patch of that diff shows that it changes those lines. That we chose to >> ignore the patch can only be seen by looking at the merge commit >> 300560577, which references the same 'tree' as the previous merge >> 'cb4e054e', meaning they both reference they same set of files: >> >> > git cat-file 300560577 -p >> tree ae2bec4f10425bd61e2a90563edc178d382bb4b8 >> [...] >> >> > git cat-file cb4e054e41c -p >> tree ae2bec4f10425bd61e2a90563edc178d382bb4b8 >> >> My best guess is that 'git annotate' does not incorporate that >> information, but I'm not familiar with the inner workings of that >> command. Maybe no one bothered to implement it, or maybe it would make >> annotation even slower. > > So I guess the fact that a commit was skipped during a merge is > something that is so hard to see that perhaps the entire issue of > skipping is moot with Git, and we shouldn't be bothered by it. Well, it's not *that* hard to see, but it usually requires to look at a span of commits. In this case, git diff cb4e054e41c..300560577 will correctly produce nothing. But I agree it's unfortunate that you cannot see this from the merge commit alone. But I'm not sure what you mean with the entire issue being moot. How do you suggest we deal with commits that shouldn't land in master? -David ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 17:52 ` David Engster @ 2016-03-25 18:43 ` Eli Zaretskii 2016-03-25 19:29 ` Óscar Fuentes 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-25 18:43 UTC (permalink / raw) To: David Engster; +Cc: johnw, emacs-devel > From: David Engster <deng@randomsample.de> > Cc: johnw@gnu.org, emacs-devel@gnu.org > Date: Fri, 25 Mar 2016 18:52:06 +0100 > > > So I guess the fact that a commit was skipped during a merge is > > something that is so hard to see that perhaps the entire issue of > > skipping is moot with Git, and we shouldn't be bothered by it. > > Well, it's not *that* hard to see, but it usually requires to look at a > span of commits. In this case, > > git diff cb4e054e41c..300560577 > > will correctly produce nothing. But I agree it's unfortunate that you > cannot see this from the merge commit alone. But I'm not sure what you > mean with the entire issue being moot. How do you suggest we deal with > commits that shouldn't land in master? Sorry, I should have made it clear I was talking only about the backported commits. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 18:43 ` Eli Zaretskii @ 2016-03-25 19:29 ` Óscar Fuentes 0 siblings, 0 replies; 68+ messages in thread From: Óscar Fuentes @ 2016-03-25 19:29 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> will correctly produce nothing. But I agree it's unfortunate that you >> cannot see this from the merge commit alone. But I'm not sure what you >> mean with the entire issue being moot. How do you suggest we deal with >> commits that shouldn't land in master? > > Sorry, I should have made it clear I was talking only about the > backported commits. A backported commit still can produce a conflict if the code affected by that commit is modified again later on master. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 17:33 ` Eli Zaretskii 2016-03-25 17:52 ` David Engster @ 2016-03-25 19:42 ` Paul Eggert 2016-03-26 21:34 ` Stefan Monnier 2 siblings, 0 replies; 68+ messages in thread From: Paul Eggert @ 2016-03-25 19:42 UTC (permalink / raw) To: Eli Zaretskii, David Engster; +Cc: johnw, emacs-devel On 03/25/2016 10:33 AM, Eli Zaretskii wrote: > So I guess the fact that a commit was skipped during a merge is > something that is so hard to see that perhaps the entire issue of > skipping is moot with Git, and we shouldn't be bothered by it. I think that's basically it, yes. I agree that 'git blame' should be blaming the mainline commit rather than the skipped backported commit. I don't know why it's blaming the skipped commit. On the other hand, this is consistent with the philosophy of not caring about how beautiful the shape of the history is, so long as each commit is accurate. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-25 17:33 ` Eli Zaretskii 2016-03-25 17:52 ` David Engster 2016-03-25 19:42 ` Paul Eggert @ 2016-03-26 21:34 ` Stefan Monnier 2 siblings, 0 replies; 68+ messages in thread From: Stefan Monnier @ 2016-03-26 21:34 UTC (permalink / raw) To: emacs-devel > So I guess the fact that a commit was skipped during a merge is > something that is so hard to see that perhaps the entire issue of > skipping is moot with Git, and we shouldn't be bothered by it. Skipping is not something really relevant from the history point of view. It's rather relevant for the one performing a merge since the main purpose to avoid spurious conflicts. Stefan ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 16:18 ` Eli Zaretskii 2016-03-22 16:30 ` Stefan Monnier @ 2016-03-22 17:00 ` Phillip Lord 2016-03-22 18:24 ` Eli Zaretskii 1 sibling, 1 reply; 68+ messages in thread From: Phillip Lord @ 2016-03-22 17:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rudalics, John Wiegley, emacs-devel, eggert Eli Zaretskii <eliz@gnu.org> writes: >> But in these cases, the commit we lost should have been mentioned in >> the list of skipped one. It wasn't, AFAICS. > > I think I know what happened. It goes like this: > > . Phillip worked on test selector for the test suite. When he > finished, he made a local commit 549a765 on the emacs-25 branch. > > . Phillip then said "git pull", followed by "git push". This > produced the merge-commit bb0cd31, which incorporated 9 other > commits that were pushed there since the time Phillip started > working on 549a765. One of these 9 commits was my commit that > fixed resize_frame_windows. Oh dear, should have made those changes on a branch and rebased from emacs-25. Phil ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 17:00 ` Phillip Lord @ 2016-03-22 18:24 ` Eli Zaretskii 2016-03-22 19:21 ` John Wiegley 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2016-03-22 18:24 UTC (permalink / raw) To: Phillip Lord; +Cc: rudalics, johnw, emacs-devel, eggert > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: John Wiegley <johnw@gnu.org>, rudalics@gmx.at, eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Tue, 22 Mar 2016 17:00:49 +0000 > > Eli Zaretskii <eliz@gnu.org> writes: > >> But in these cases, the commit we lost should have been mentioned in > >> the list of skipped one. It wasn't, AFAICS. > > > > I think I know what happened. It goes like this: > > > > . Phillip worked on test selector for the test suite. When he > > finished, he made a local commit 549a765 on the emacs-25 branch. > > > > . Phillip then said "git pull", followed by "git push". This > > produced the merge-commit bb0cd31, which incorporated 9 other > > commits that were pushed there since the time Phillip started > > working on 549a765. One of these 9 commits was my commit that > > fixed resize_frame_windows. > > Oh dear, should have made those changes on a branch and rebased from > emacs-25. It's not your fault. Quite a few others (myself included) produce these merge-commits from time to time, this cannot be avoided. The problem is in the merge procedure from emacs-25 to master -- it shouldn't skip such merge-commits. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 18:24 ` Eli Zaretskii @ 2016-03-22 19:21 ` John Wiegley 2016-03-22 19:46 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: John Wiegley @ 2016-03-22 19:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rudalics, eggert, emacs-devel, Phillip Lord >>>>> Eli Zaretskii <eliz@gnu.org> writes: > It's not your fault. Quite a few others (myself included) produce these > merge-commits from time to time, this cannot be avoided. The problem is in > the merge procedure from emacs-25 to master -- it shouldn't skip such > merge-commits. One take away from this is to be very cautious in assessing whether merge commits should really be skipped or not. What is the criteria for knowing when they *should* be skipped? Checking to ensure that all those commits are already on master? -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Missing changes in merges from emacs-25 to master 2016-03-22 19:21 ` John Wiegley @ 2016-03-22 19:46 ` Eli Zaretskii 0 siblings, 0 replies; 68+ messages in thread From: Eli Zaretskii @ 2016-03-22 19:46 UTC (permalink / raw) To: John Wiegley; +Cc: rudalics, eggert, emacs-devel, phillip.lord > From: John Wiegley <jwiegley@gmail.com> > Cc: phillip.lord@russet.org.uk (Phillip Lord), rudalics@gmx.at, eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Tue, 22 Mar 2016 12:21:10 -0700 > > >>>>> Eli Zaretskii <eliz@gnu.org> writes: > > > It's not your fault. Quite a few others (myself included) produce these > > merge-commits from time to time, this cannot be avoided. The problem is in > > the merge procedure from emacs-25 to master -- it shouldn't skip such > > merge-commits. > > One take away from this is to be very cautious in assessing whether merge > commits should really be skipped or not. What is the criteria for knowing > when they *should* be skipped? Checking to ensure that all those commits are > already on master? That would be a lot of work, IMO. I actually don't understand why we should skip _any_ merge-commits. Can you (or someone else) describe a situation where merging such commits to master wouldn't be TRT? ^ permalink raw reply [flat|nested] 68+ messages in thread
end of thread, other threads:[~2016-03-26 21:34 UTC | newest] Thread overview: 68+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-03-20 11:36 Missing changes in merges from emacs-25 to master martin rudalics 2016-03-20 17:32 ` Eli Zaretskii 2016-03-20 18:38 ` martin rudalics 2016-03-20 18:50 ` Eli Zaretskii 2016-03-20 19:15 ` martin rudalics 2016-03-21 7:36 ` Paul Eggert 2016-03-21 9:22 ` martin rudalics 2016-03-21 17:55 ` Paul Eggert 2016-03-22 10:22 ` martin rudalics 2016-03-22 10:36 ` Andreas Schwab 2016-03-22 10:58 ` martin rudalics 2016-03-22 11:32 ` Andreas Schwab 2016-03-22 11:47 ` martin rudalics 2016-03-22 15:20 ` Óscar Fuentes 2016-03-22 17:08 ` martin rudalics 2016-03-22 15:24 ` Noam Postavsky 2016-03-22 17:08 ` martin rudalics 2016-03-21 16:06 ` Eli Zaretskii 2016-03-21 17:55 ` John Wiegley 2016-03-21 17:57 ` Paul Eggert 2016-03-21 18:16 ` Eli Zaretskii 2016-03-21 21:27 ` John Wiegley 2016-03-22 0:17 ` Paul Eggert 2016-03-22 0:52 ` Paul Eggert 2016-03-22 3:35 ` Eli Zaretskii 2016-03-22 16:18 ` Eli Zaretskii 2016-03-22 16:30 ` Stefan Monnier 2016-03-22 16:45 ` Eli Zaretskii 2016-03-22 16:52 ` Stefan Monnier 2016-03-22 17:03 ` Eli Zaretskii 2016-03-22 18:21 ` Paul Eggert 2016-03-22 18:33 ` Eli Zaretskii 2016-03-23 13:10 ` Stefan Monnier 2016-03-22 18:41 ` Stefan Monnier 2016-03-22 18:58 ` Eli Zaretskii 2016-03-23 2:08 ` Stefan Monnier 2016-03-23 8:07 ` Andreas Schwab 2016-03-22 19:34 ` Lars Magne Ingebrigtsen 2016-03-22 19:49 ` Eli Zaretskii 2016-03-24 7:18 ` Phillip Lord 2016-03-22 18:32 ` Paul Eggert 2016-03-22 18:37 ` Eli Zaretskii 2016-03-22 19:15 ` Paul Eggert 2016-03-22 19:42 ` Eli Zaretskii 2016-03-22 20:26 ` Paul Eggert 2016-03-22 22:57 ` David Engster 2016-03-22 23:45 ` Paul Eggert 2016-03-25 8:52 ` Eli Zaretskii 2016-03-25 9:14 ` Andreas Schwab 2016-03-25 10:48 ` Eli Zaretskii 2016-03-25 11:50 ` Andreas Schwab 2016-03-25 13:55 ` Eli Zaretskii 2016-03-25 9:15 ` David Engster 2016-03-25 10:50 ` Eli Zaretskii 2016-03-25 11:38 ` David Engster 2016-03-25 14:15 ` Eli Zaretskii 2016-03-25 16:00 ` David Engster 2016-03-25 16:27 ` David Engster 2016-03-25 17:33 ` Eli Zaretskii 2016-03-25 17:52 ` David Engster 2016-03-25 18:43 ` Eli Zaretskii 2016-03-25 19:29 ` Óscar Fuentes 2016-03-25 19:42 ` Paul Eggert 2016-03-26 21:34 ` Stefan Monnier 2016-03-22 17:00 ` Phillip Lord 2016-03-22 18:24 ` Eli Zaretskii 2016-03-22 19:21 ` John Wiegley 2016-03-22 19:46 ` 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.