From: Bojan Nikolic <bojan@bnikolic.co.uk>
To: emacs-devel@gnu.org
Subject: Re: Bzr document unclear. There is no "conflict markers".
Date: Sun, 03 Jan 2010 22:36:49 +0000 [thread overview]
Message-ID: <871vi6izni.fsf@bnikolic.co.uk> (raw)
In-Reply-To: E1NRYUR-0001UF-Ho@fencepost.gnu.org
Hi Richard,
Richard Stallman <rms@gnu.org> writes:
> I think it is usually better do the merge first (and resolve any
> possible conflicts) before making the edits that make up your fix.
>
> I find that hard to understand. If you have not yet edited the file,
> what is there to merge? All you could do is update, right?
>
> Is there something I don't understand here?
The quick answer is that the "quickfixes" branch could have diverged
from the trunk, for example because some of the developers changes have
not been accepted (yet) into the trunk.
Reviewing the wiki document, I do not it is completely clear on this
topic. The current text on the wiki on this is as follows
(http://www.emacswiki.org/emacs/BzrForEmacsDevs#toc12):
cd $DEVHOME/emacs/trunk
bzr update # update from the upstream master
cd ../quickfixes
bzr merge # update from /trunk/ (optional)
The reason you use “merge” instead of “update” in the task branch is
that your task branch has local changes – it has diverged (a bit)
from the upstream master, and so any changes from upstream have to
be merged with your changes.
I think there are a few things to add to this.
Firstly, it is not really correct that in the "quickfixes" directory
there is a choice between running "bzr merge" or "bzr update". In fact
(I believe) it is a choice between "bzr merge" and "bzr pull".
Recall, "bzr pull" can incorporate changes where there is no divergence
in history. In this case that will be true if the last revision
quickfixes is on the direct history line of the current last revision in
trunk.
If the histories have diverged, then "bzr merge" must be invoked to
combine them. One possible reason why the histories could have diverged
is that some of the changes that the developer has made on the
quick-fixes branch have not yet been accepted into trunk.
Secondly, if "bzr merge --pull " is called by the developer but "bzr
pull" would have succeeded (because in fact there has been no divergence
in history) then the results is exactly equivalent to "bzr
pull". Therefore I think in these situations it is better to do use the
--pull option to merge.
Best,
Bojan
--
Bojan Nikolic || http://www.bnikolic.co.uk
next prev parent reply other threads:[~2010-01-03 22:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-03 12:44 Bzr document unclear. There is no "conflict markers" Jan Djärv
2010-01-03 13:39 ` Eli Zaretskii
2010-01-03 14:33 ` Jan Djärv
2010-01-03 15:10 ` Eli Zaretskii
2010-01-03 19:17 ` Jan Djärv
2010-01-03 19:25 ` Eli Zaretskii
2010-01-04 0:14 ` Jan Djärv
2010-01-03 15:24 ` Bojan Nikolic
2010-01-03 21:59 ` Richard Stallman
2010-01-03 22:36 ` Bojan Nikolic [this message]
2010-01-04 16:23 ` Richard Stallman
2010-01-04 17:08 ` Stefan Monnier
2010-01-04 20:07 ` Bojan Nikolic
2010-01-04 4:08 ` Eli Zaretskii
2010-01-04 16:23 ` Richard Stallman
2010-01-04 18:27 ` 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=871vi6izni.fsf@bnikolic.co.uk \
--to=bojan@bnikolic.co.uk \
--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.