From: Eli Zaretskii <eliz@gnu.org>
To: Lennart Borgman <lennart.borgman@gmail.com>
Cc: keramida@ceid.upatras.gr, acm@muc.de, emacs-devel@gnu.org
Subject: Re: Help me unstick my bzr, please.
Date: Sat, 16 Jan 2010 13:17:39 +0200 [thread overview]
Message-ID: <837hricn8s.fsf@gnu.org> (raw)
In-Reply-To: <e01d8a51001160202o51559d6ftad3ae793f910d097@mail.gmail.com>
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Sat, 16 Jan 2010 11:02:50 +0100
> Cc: keramida@ceid.upatras.gr, acm@muc.de, emacs-devel@gnu.org
>
> > bzr merge
> > bzr commit
> >
> > The first one merges the text of the files, but does not combine their
> > histories. The second command finishes the merging process by
> > updating the history so that it now includes both local commits and
> > whatever happened in the mainline since the last time you merged from
> > it.
>
>
> Thanks Eli, but what worries me is that it looks like one could take a
> completely wrong path here after "bzr merge". I might be
> misunderstanding something but it looks to me like Alan's quick fix
> branch got into a bad state just because he did not do "bzr commit"
> immediately.
I think "bad state" is an exaggeration. E.g., Giorgos just posted one
simple way out of this predicament; there are many others.
And yes, if you work in a branch, you need to grow genes to do a
"bzr commit" immediately after "bzr merge". Note that a similar
trouble could happen to you if you "cvs up" with uncommitted changes
in the sandbox, and some of the updates conflict with your local
changes.
> Is that really true??? If so why does not bazaar protect against this?
It's really easy to get out of this "bad state". No more complicated
than with CVS.
next prev parent reply other threads:[~2010-01-16 11:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-15 22:27 Help me unstick my bzr, please Alan Mackenzie
2010-01-16 2:37 ` Giorgos Keramidas
2010-01-16 7:48 ` Eli Zaretskii
2010-01-16 8:29 ` Stephen J. Turnbull
2010-01-16 8:41 ` Stephen J. Turnbull
2010-01-16 8:59 ` Eli Zaretskii
2010-01-17 6:04 ` Stephen J. Turnbull
2010-01-16 9:02 ` Giorgos Keramidas
2010-01-16 9:57 ` Eli Zaretskii
2010-01-16 10:04 ` Giorgos Keramidas
2010-01-16 9:16 ` Lennart Borgman
2010-01-16 9:53 ` Andreas Schwab
2010-01-16 9:54 ` Eli Zaretskii
2010-01-16 9:59 ` Giorgos Keramidas
2010-01-16 10:02 ` Lennart Borgman
2010-01-16 11:17 ` Eli Zaretskii [this message]
2010-01-17 6:23 ` Simple unsticking with 'bzr shelve' [was: Help me unstick ...] Stephen J. Turnbull
2010-01-16 19:36 ` Help me unstick my bzr, please Stefan Monnier
2010-01-16 21:38 ` Alan Mackenzie
2010-01-17 7:50 ` Giorgos Keramidas
2010-01-16 10:10 ` Eli Zaretskii
2010-01-16 21:27 ` Alan Mackenzie
2010-01-16 21:32 ` Juanma Barranquero
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=837hricn8s.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=keramida@ceid.upatras.gr \
--cc=lennart.borgman@gmail.com \
/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).