From: Eli Zaretskii <eliz@gnu.org>
To: David Engster <deng@randomsample.de>
Cc: johnw@gnu.org, emacs-devel@gnu.org
Subject: Re: Missing changes in merges from emacs-25 to master
Date: Fri, 25 Mar 2016 20:33:55 +0300 [thread overview]
Message-ID: <8360wa1myk.fsf@gnu.org> (raw)
In-Reply-To: <87d1qi5yz6.fsf@engster.org> (message from David Engster on Fri, 25 Mar 2016 17:00:45 +0100)
> 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.
next prev parent reply other threads:[~2016-03-25 17:33 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 [this message]
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
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=8360wa1myk.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=deng@randomsample.de \
--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.