* 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 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 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 ` 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-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 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 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: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 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 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-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 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 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 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: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: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 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: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 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 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: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: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
* 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: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 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 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 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-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 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: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 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 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 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
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.