From: David Engster <deng@randomsample.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: johnw@gnu.org, emacs-devel@gnu.org
Subject: Re: Missing changes in merges from emacs-25 to master
Date: Fri, 25 Mar 2016 18:52:06 +0100 [thread overview]
Message-ID: <874mbu5ttl.fsf@engster.org> (raw)
In-Reply-To: <8360wa1myk.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 25 Mar 2016 20:33:55 +0300")
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
next prev parent reply other threads:[~2016-03-25 17:52 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874mbu5ttl.fsf@engster.org \
--to=deng@randomsample.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=johnw@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.