unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Óscar Fuentes" <ofv@wanadoo.es>
To: emacs-devel@gnu.org
Subject: Re: Confusing "bzr log" as result of merges
Date: Sat, 21 May 2011 19:09:35 +0200	[thread overview]
Message-ID: <8762p42d68.fsf@wanadoo.es> (raw)
In-Reply-To: 83tycodmog.fsf@gnu.org

Eli Zaretskii <eliz@gnu.org> writes:

>> Create a branch emacs-common and commit there all the changes intended
>> for emacs-23 and trunk.
>
> Given that the trunk and the branch diverge quite quickly, I don't
> think what you suggest is practical.  The divergence is in the basic
> infrastructure, such as access to global variables and members of
> buffer and keyboard objects.  That makes such a common branch
> problematic, as it is not clear which one of the diverging branches it
> should follow, and how to be sure that all 3 branches "work".

emacs-common does not need to "work" (nor even compile!) It is just a
temporary storage for submitted revisions, with the net result of
producing a cleaner history, reducing housekeeping and diminishing the
frequency of errors ("bzr merge" is less error-prone than an humane
figuring out which revisions need to be cherry-picked.)

>> From time to time *merge* (not cherry-pick!)  emacs-common into
>> emacs-23 and trunk.
>
> We merge already, but then reverse cherry-pick those revisions that
> are not intended for the trunk, before committing.  At least this is
> my understanding of how merges from the branch work.

I thought that you do both: cherry-picking from emacs-23 into trunk and
merging emacs-23 into trunk. But even if that's is not so, reverting
(reversing, as you say) the commits that does not belong into trunk
creates a messy history. This is undesirable.

>> Long time ago I advised against mixing cherry-picks and merges and
>> suggested this strategy, but was discarded because it is too
>> complex. I'm sure that as time passes and you get bitten again and again
>> by the current practice it will finally look extremely simple.
>
> Since no one is even bothered by these issues, I very much doubt that
> anything will be done any time soon.

I thought that the existence of this thread demonstrates that someone is
bothered by these issues.




  reply	other threads:[~2011-05-21 17:09 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-21  7:33 Confusing "bzr log" as result of merges Eli Zaretskii
2011-05-21  8:36 ` Andreas Schwab
2011-05-21  8:44   ` Eli Zaretskii
2011-05-21  8:48     ` Eli Zaretskii
2011-05-21  9:01     ` Sven Joachim
2011-05-21  9:16       ` Eli Zaretskii
2011-05-21  9:27         ` Sven Joachim
2011-05-21  9:30           ` Eli Zaretskii
2011-05-21 10:27             ` Sven Joachim
2011-05-21  9:02     ` Andreas Schwab
2011-05-21  9:20       ` Eli Zaretskii
2011-05-21  9:38         ` Andreas Schwab
2011-05-21 10:33           ` Eli Zaretskii
2011-05-21 10:54             ` Andreas Schwab
2011-05-21 10:38 ` Eli Zaretskii
2011-05-21 10:56   ` Andreas Schwab
2011-05-21 11:27     ` Eli Zaretskii
2011-05-21 12:23       ` Andreas Schwab
2011-05-21 12:28         ` Eli Zaretskii
2011-05-21 10:57   ` Sven Joachim
2011-05-21 13:04   ` Eli Zaretskii
2011-05-21 13:37     ` Andreas Schwab
2011-05-21 14:46       ` Eli Zaretskii
2011-05-21 15:18         ` Andreas Schwab
2011-05-21 15:51           ` Eli Zaretskii
2011-05-21 16:39             ` Andreas Schwab
2011-05-21 16:21 ` Óscar Fuentes
2011-05-21 16:42   ` Andreas Schwab
2011-05-21 17:00     ` Óscar Fuentes
2011-05-21 17:06       ` Andreas Schwab
2011-05-21 17:19         ` Óscar Fuentes
2011-05-21 17:52           ` Andreas Schwab
2011-05-22 11:33           ` Juanma Barranquero
2011-05-21 16:48   ` Eli Zaretskii
2011-05-21 17:09     ` Óscar Fuentes [this message]
2011-05-21 18:56       ` Eli Zaretskii
2011-05-21 17:27 ` Glenn Morris
2011-05-21 19:02   ` Eli Zaretskii
2011-05-22  1:46     ` Glenn Morris
2011-05-22 14:14 ` Stefan Monnier
2011-05-22 17:28   ` Eli Zaretskii
2011-05-22 19:15     ` Stefan Monnier
2011-05-23  3:01       ` Eli Zaretskii
2011-05-23 12:02         ` Stefan Monnier
2011-05-23 12:58           ` 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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8762p42d68.fsf@wanadoo.es \
    --to=ofv@wanadoo.es \
    --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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).