From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Latest merge from the emacs-23 branch
Date: Sun, 19 Dec 2010 08:47:18 -0500 [thread overview]
Message-ID: <jwvhbe9sx58.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83hbebf0dd.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 18 Dec 2010 19:37:34 +0200")
> Okay, then how about including with the merge commit message the list
> of revisions you backed out after merging? This list cannot be too
> long (otherwise merging doesn't make sense).
Actually, the list can be any length and the merge would still make
sense, because the merge of changes we actually don't want is performed
to make future merges easier (and to keep track of the fact that we
already did what we had to do with these changes (i.e. "not merge it")).
In practice the list tends to be reasonably short (since it only
includes things like backports plus a few changes that are already
overridden on the trunk, like changing the release number). So we could
probably include it, tho it's more work. Currently, the output that my
script gets doesn't mention revision ids, only revision numbers and log
messages, so maybe we could just include the first line of commit
messages instead of revision ids.
>> > No, there actually seem to be 2 different revisions on the trunk now that
>> > appear to solve the same issue in two different ways. For example, this
>> > "merge":
>> > 99634.2.670: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs
>> > is also present here:
>> > 102637: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs
>> Yup. This is a non-issue.
> It will be a non-issue if there's a way to know that 99634.2.670 was
> reverse cherry-picked after merging. Otherwise, how can I distinguish
> between this case and the case of erroneously merging from the branch
> (which happened in the past)?
By looking at the code. Even with more metadata, only the code can tell
you what was actually changed since the metadata can only tell you what
bzr commands were used (and even that only to a limited extent since my
script uses various ways to cheat around bzr's limitations), but not how
conflicts were resolved manually or what extra manual changes
were performed.
Stefan
next prev parent reply other threads:[~2010-12-19 13:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-17 16:03 Latest merge from the emacs-23 branch Eli Zaretskii
2010-12-17 18:19 ` Andreas Schwab
2010-12-17 19:22 ` Eli Zaretskii
2010-12-17 22:03 ` Stefan Monnier
2010-12-17 23:06 ` Eli Zaretskii
2010-12-18 15:58 ` Stefan Monnier
2010-12-18 17:37 ` Eli Zaretskii
2010-12-19 13:47 ` Stefan Monnier [this message]
2010-12-19 15:10 ` 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=jwvhbe9sx58.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@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.