Help me unstick my bzr, please.

Help me unstick my bzr, please.

[Alan Mackenzie]

Hi, Emacs,

I've been struggling with this fine distributed version control system
for over a week now.  My trouble is that I have no mental picture of
what the main bits are in bzr and what the relationships between them
are.  I don't find the bazaar documentation much help in forming such a
mental picture.

Specific problem: I have just fixed a bug in my "quickfixes" branch.
This involved changing a single C file and .../src/ChangeLog.  I
attempt to merge the change into my "trunk" branch by doing this:

    ~/emacs/emacs.bzr/quickfixes$ bzr merge

I get this error message:

    bzr: ERROR: Working tree "/home/acm/emacs/emacs.bzr/quickfixes/" has
    uncommitted changes (See bzr status).

When I execute bzr status, it gives me a list of ~55 allegedly modified
files, finishing up with:

    pending merge tips: (use -v to see all merge revisions)
      Jan D. 2010-01-06 [merge] Fix slowdown and wrong font choosed by XSETTINGS...
      
Would somebody please tell me what I might have done to make bzr think
I've got 55 modified files?  How might I recover from this?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Help me unstick my bzr, please.

[Giorgos Keramidas]

On Fri, 15 Jan 2010 22:27:24 +0000, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Emacs,
>
> I've been struggling with this fine distributed version control system
> for over a week now.  My trouble is that I have no mental picture of
> what the main bits are in bzr and what the relationships between them
> are.  I don't find the bazaar documentation much help in forming such a
> mental picture.
>
> Specific problem: I have just fixed a bug in my "quickfixes" branch.
> This involved changing a single C file and .../src/ChangeLog.  I
> attempt to merge the change into my "trunk" branch by doing this:
>
>     ~/emacs/emacs.bzr/quickfixes$ bzr merge
>
> I get this error message:
>
>     bzr: ERROR: Working tree "/home/acm/emacs/emacs.bzr/quickfixes/" has
>     uncommitted changes (See bzr status).
>
> When I execute bzr status, it gives me a list of ~55 allegedly modified
> files, finishing up with:
>
>     pending merge tips: (use -v to see all merge revisions)
>       Jan D. 2010-01-06 [merge] Fix slowdown and wrong font choosed by XSETTINGS...
>
> Would somebody please tell me what I might have done to make bzr think
> I've got 55 modified files?  How might I recover from this?

The "pending merge" message means that in the past (before you made the
quick fix to the two files) you did:

    bzr merge

This pulled stuff from the local trunk branch, and merged it with your
local quickfixes branch.  But you have to also run "bzr commit" to
complete the fix.  You didn't at the time, so the quickfixes branch
remains in a "the merge has locally finished but it is uncommitted"
state.

I think the easiest way to revert your local "quickfixes" branch to a
known & sane state is something like:

    1. Keep a backup of the two files you modified.
    2. Wipe the local quickfixes branch.
    3. Re-create the quickfixes from trunk.
    4. Overwre the two files in the new quickfixes branch.
    5. Use "bzr diff" to inspect the changes.
    6. Commit them with "bzr commit".

HTH,
Giorgos

Re: Help me unstick my bzr, please.

[Eli Zaretskii]

> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
> Date: Sat, 16 Jan 2010 04:37:24 +0200
> Cc: emacs-devel@gnu.org
> 
> > When I execute bzr status, it gives me a list of ~55 allegedly modified
> > files, finishing up with:
> >
> >     pending merge tips: (use -v to see all merge revisions)
> >       Jan D. 2010-01-06 [merge] Fix slowdown and wrong font choosed by XSETTINGS...
> >
> > Would somebody please tell me what I might have done to make bzr think
> > I've got 55 modified files?  How might I recover from this?
> 
> The "pending merge" message means that in the past (before you made the
> quick fix to the two files) you did:
> 
>     bzr merge
> 
> This pulled stuff from the local trunk branch, and merged it with your
> local quickfixes branch.  But you have to also run "bzr commit" to
> complete the fix.  You didn't at the time, so the quickfixes branch
> remains in a "the merge has locally finished but it is uncommitted"
> state.

That's probably what happened.

> I think the easiest way to revert your local "quickfixes" branch to a
> known & sane state is something like:
> 
>     1. Keep a backup of the two files you modified.
>     2. Wipe the local quickfixes branch.
>     3. Re-create the quickfixes from trunk.
>     4. Overwre the two files in the new quickfixes branch.
>     5. Use "bzr diff" to inspect the changes.
>     6. Commit them with "bzr commit".

Why not simply

  ~/emacs/emacs.bzr/quickfixes$ bzr merge --force

?  Then Alan could continue with the normal quickfixes workflow:

  ~/emacs/emacs.bzr/quickfixes$ cd ../trunk
  ~/emacs/emacs.bzr/trunk$ bzr update
  ~/emacs/emacs.bzr/trunk$ bzr merge ../quickfixes
  ~/emacs/emacs.bzr/trunk$ bzr commit -m "Fixed bug #1234."

Are there any problems with using --force in this case?

(From the discussions on the Bazaar list, I understand that some very
near future version will make "bzr merge" display a warning when there
are uncommitted changes, instead of erroring out.  So the above would
happen for Alan anyway, in that future version.)

Re: Help me unstick my bzr, please.

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Why not simply
 > 
 >   ~/emacs/emacs.bzr/quickfixes$ bzr merge --force
 > 
 > ?  Then Alan could continue with the normal quickfixes workflow:

Because IIUC the situation correctly, Alan's work would show up as a
merge commit, not as a commit to a branch.  IOW, in the logs (or a
graphical DAG viewer) it would look like he was resolving conflicts in
the merge of those commits, not committing new work.

For tiny changes this is a pretty pedantic distinction, and for humans
the log message would probably make what happened clear.

For larger changes, this could cause problems (ie, less accurate
localization of the responsible change) using tools like bisect; I'd
have to think about it.

Re: Help me unstick my bzr, please.

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Why not simply
 > 
 >   ~/emacs/emacs.bzr/quickfixes$ bzr merge --force

Because Alan's commit will be a merge commit, not a regular commit.
This probably won't confuse most humans, who will be looking at Alan's
commit message, not at the parentage of the commit, but it might cause
issues with DAG tracing tools like bisect.

It will also very likely cause Alan's commit to appear to be the
mainline, and all of the commits he has merged to be a feature branch,
in the logs and GUI DAG viewers.  This would be disconcerting to
experienced bzr users.

Re: Help me unstick my bzr, please.

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Giorgos Keramidas <keramida@ceid.upatras.gr>,
>     acm@muc.de,
>     emacs-devel@gnu.org
> Date: Sat, 16 Jan 2010 17:41:10 +0900
> 
> Eli Zaretskii writes:
> 
>  > Why not simply
>  > 
>  >   ~/emacs/emacs.bzr/quickfixes$ bzr merge --force
> 
> Because Alan's commit will be a merge commit, not a regular commit.
> This probably won't confuse most humans, who will be looking at Alan's
> commit message, not at the parentage of the commit, but it might cause
> issues with DAG tracing tools like bisect.

For such a small change, I doubt if this is significant.

> It will also very likely cause Alan's commit to appear to be the
> mainline, and all of the commits he has merged to be a feature branch,
> in the logs and GUI DAG viewers.

Sorry, I don't understand what you mean by ``appear to be mainline''
and by ``commits [...] to be a feature branch''.  Can you elaborate?

Re: Help me unstick my bzr, please.

[Giorgos Keramidas]

On Sat, 16 Jan 2010 09:48:51 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
>> Date: Sat, 16 Jan 2010 04:37:24 +0200
>> Cc: emacs-devel@gnu.org
>>
>> > When I execute bzr status, it gives me a list of ~55 allegedly modified
>> > files, finishing up with:
>> >
>> >     pending merge tips: (use -v to see all merge revisions)
>> >       Jan D. 2010-01-06 [merge] Fix slowdown and wrong font choosed by XSETTINGS...
>> >
>> > Would somebody please tell me what I might have done to make bzr think
>> > I've got 55 modified files?  How might I recover from this?
>>
>> I think the easiest way to revert your local "quickfixes" branch to a
>> known & sane state is something like:
>>
>>     1. Keep a backup of the two files you modified.
>>     2. Wipe the local quickfixes branch.
>>     3. Re-create the quickfixes from trunk.
>>     4. Overwre the two files in the new quickfixes branch.
>>     5. Use "bzr diff" to inspect the changes.
>>     6. Commit them with "bzr commit".
>
> Why not simply
>
>   ~/emacs/emacs.bzr/quickfixes$ bzr merge --force

To be honest, because I don't know for sure what merge --force does
under the hood.

It sounds like it will solve the immediate problem of having a
quickfixes branch half-way through a merge, but it also seems it will
create a merge commit that includes both the pending merge changes *and*
the small fix in the same changes.

For a tiny change it will probably be easy to understand which part of
the changes is a merge and which other parts are new.  For larger
changes I'm not sure if it will look ok in the DAG of the history,
especially if the quick and small fix is very localized and will be
pushed to the trunk in short order.

Re: Help me unstick my bzr, please.

[Lennart Borgman]

On Sat, Jan 16, 2010 at 8:48 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > When I execute bzr status, it gives me a list of ~55 allegedly modified
>> > files, finishing up with:
>> >
>> >     pending merge tips: (use -v to see all merge revisions)
>> >       Jan D. 2010-01-06 [merge] Fix slowdown and wrong font choosed by XSETTINGS...
>> >
>> > Would somebody please tell me what I might have done to make bzr think
>> > I've got 55 modified files?  How might I recover from this?
>>
>> The "pending merge" message means that in the past (before you made the
>> quick fix to the two files) you did:
>>
>>     bzr merge
>>
>> This pulled stuff from the local trunk branch, and merged it with your
>> local quickfixes branch.  But you have to also run "bzr commit" to
>> complete the fix.  You didn't at the time, so the quickfixes branch
>> remains in a "the merge has locally finished but it is uncommitted"
>> state.
>
> That's probably what happened.


I do not understand. Can someone please explain to me why a bazaar
user have to take care of this?

Re: Help me unstick my bzr, please.

[Andreas Schwab]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> I do not understand. Can someone please explain to me why a bazaar
> user have to take care of this?

Because Bazaar Is Not Git.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Help me unstick my bzr, please.

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Sat, 16 Jan 2010 10:16:37 +0100
> Cc: Giorgos Keramidas <keramida@ceid.upatras.gr>, acm@muc.de, emacs-devel@gnu.org
> 
> On Sat, Jan 16, 2010 at 8:48 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >>
> >> > When I execute bzr status, it gives me a list of ~55 allegedly modified
> >> > files, finishing up with:
> >> >
> >> >     pending merge tips: (use -v to see all merge revisions)
> >> >       Jan D. 2010-01-06 [merge] Fix slowdown and wrong font choosed by XSETTINGS...
> >> >
> >> > Would somebody please tell me what I might have done to make bzr think
> >> > I've got 55 modified files?  How might I recover from this?
> >>
> >> The "pending merge" message means that in the past (before you made the
> >> quick fix to the two files) you did:
> >>
> >>     bzr merge
> >>
> >> This pulled stuff from the local trunk branch, and merged it with your
> >> local quickfixes branch.  But you have to also run "bzr commit" to
> >> complete the fix.  You didn't at the time, so the quickfixes branch
> >> remains in a "the merge has locally finished but it is uncommitted"
> >> state.
> >
> > That's probably what happened.
> 
> 
> I do not understand. Can someone please explain to me why a bazaar
> user have to take care of this?

It's in the workflow described on the wiki: the process of merging a
branch with the mainline involves two commands:

  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.

Note that there could be conflicts reported by "bzr merge", in which
case you should resolve them manually, then use a 3rd command to tell
Bazaar that the conflicts were resolved:

  bzr resolve file1 file2 file3 ...

where the named files are those where you resolved the conflicts.
This 3rd command should come between "bzr merge" (which reports the
conflicts in the first place) and "bzr commit".

These complications are the reason why IMO using a separate branch for
``quick fixes'' is not the best way.  Doing such simple changes
directly in the trunk, or in a separate branch that is bound to the
remote repository, is much better.  The latest version of
BzrForEmacsDevs page on the wiki suggest these latter 2 possibilities,
but Alan is using the previous suggestion, whereby the quickfixes
branch was a local branch with the trunk mirror its parent.

The workflow with a local branch whose parent is the trunk mirror is
IMO better suited to working on a non-trivial set of changes or a new
feature.  That's because this kind of job is probably not finished in
one go, and you need to return to it in the course of several days or
even weeks.  So you will want to be isolated from changes on the trunk
for a while.  Also, separating feature development into a separate
branch will allow you to make simple unrelated changes on the trunk at
the same time, without having your local changes get in your way.

With such a significant development branch, the overhead of merging
from the trunk from time to time is justified.  With simple changes,
it is not, IMO.

Re: Help me unstick my bzr, please.

[Eli Zaretskii]

> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
> Cc: acm@muc.de, emacs-devel@gnu.org
> Date: Sat, 16 Jan 2010 11:02:04 +0200
> 
> > Why not simply
> >
> >   ~/emacs/emacs.bzr/quickfixes$ bzr merge --force
> 
> To be honest, because I don't know for sure what merge --force does
> under the hood.
> 
> It sounds like it will solve the immediate problem of having a
> quickfixes branch half-way through a merge, but it also seems it will
> create a merge commit that includes both the pending merge changes *and*
> the small fix in the same changes.

Except for "bzr bisect", who else will be bothered by this?

Re: Help me unstick my bzr, please.

[Giorgos Keramidas]

On Sat, 16 Jan 2010 11:54:41 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> I do not understand. Can someone please explain to me why a bazaar
>> user have to take care of this?
>
> It's in the workflow described on the wiki: the process of merging a
> branch with the mainline involves two commands:
>
>   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.

Exactly.  This is not a 'problem' of bazaar, FWIW.  I's just the way
things work in all DVCS when you have committed local changes in a
non-bound branch.

Thank you Eli for writing up a very detailed explanation :-)

Re: Help me unstick my bzr, please.

[Lennart Borgman]

On Sat, Jan 16, 2010 at 10:54 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> >
>> >> > Would somebody please tell me what I might have done to make bzr think
>> >> > I've got 55 modified files?  How might I recover from this?
>> >>
>> >> The "pending merge" message means that in the past (before you made the
>> >> quick fix to the two files) you did:
>> >>
>> >>     bzr merge
>> >>
>> >> This pulled stuff from the local trunk branch, and merged it with your
>> >> local quickfixes branch.  But you have to also run "bzr commit" to
>> >> complete the fix.  You didn't at the time, so the quickfixes branch
>> >> remains in a "the merge has locally finished but it is uncommitted"
>> >> state.
>> >
>> > That's probably what happened.
>>
>>
>> I do not understand. Can someone please explain to me why a bazaar
>> user have to take care of this?
>
> It's in the workflow described on the wiki: the process of merging a
> branch with the mainline involves two commands:
>
>  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.

Is that really true??? If so why does not bazaar protect against this?

Re: Help me unstick my bzr, please.

[Giorgos Keramidas]

On Sat, 16 Jan 2010 11:57:03 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
>> Cc: acm@muc.de, emacs-devel@gnu.org
>> Date: Sat, 16 Jan 2010 11:02:04 +0200
>>
>> > Why not simply
>> >
>> >   ~/emacs/emacs.bzr/quickfixes$ bzr merge --force
>>
>> To be honest, because I don't know for sure what merge --force does
>> under the hood.
>>
>> It sounds like it will solve the immediate problem of having a
>> quickfixes branch half-way through a merge, but it also seems it will
>> create a merge commit that includes both the pending merge changes *and*
>> the small fix in the same changes.
>
> Except for "bzr bisect", who else will be bothered by this?

It's conceivable that nobody will notice.  Committing a merge that joins
two history 'heads' in the DAG separately and then a small diff on top
of that serves mostly as a very easy way to keep the diff of the quick
fix really-really small.  This is a useful property, but it's not like
the world will end if we don't do it.

Re: Help me unstick my bzr, please.

[Eli Zaretskii]

> Date: Fri, 15 Jan 2010 22:27:24 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> I've been struggling with this fine distributed version control system
> for over a week now.  My trouble is that I have no mental picture of
> what the main bits are in bzr and what the relationships between them
> are.

My personal conclusion is that you don't really need to create a new
mental picture.  You can largely reuse the one you had about CVS.
(There are some _new_ bits to get used to, especially when you decide
to work on a significant new feature on a local branch.  But you don't
need to struggle with these new bits until you actually decide to do
such work.)

To reuse your CVS mental model, just use the "Doing Quick Fixes"
workflow as it is described on the wiki.  Note that the recommended
workflow was changed since you have read it, because it no longer
proposes to use a separate local branch, but rather either do it in
the trunk or in a branch that is bound to upstream, exactly like the
trunk is.

> I don't find the bazaar documentation much help in forming such a
> mental picture.

That's true, unfortunately.  Feel free to ask questions here, though.

Re: Help me unstick my bzr, please.

[Eli Zaretskii]

> 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.

Re: Help me unstick my bzr, please.

[Stefan Monnier]

>> 6. Commit them with "bzr commit".
> Why not simply
>   $ bzr merge --force

Other than the issues already mentioned, there's also the fact that
Bazaar developpers discourage its use and are not very interested in
making it work right.  So, among other things, this will tend to remerge
things that were already merged and then create spurious conflicts.
It may get confused in other ways as well, I just know that the few
times I tried to use it, I quickly got sufficiently annoyed that
I consider it basically unusable.


        Stefan

Re: Help me unstick my bzr, please.

[Alan Mackenzie]

Hi, Eli,

On Sat, Jan 16, 2010 at 12:10:53PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 15 Jan 2010 22:27:24 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > I've been struggling with this fine distributed version control
> > system for over a week now.  My trouble is that I have no mental
> > picture of what the main bits are in bzr and what the relationships
> > between them are.

> My personal conclusion is that you don't really need to create a new
> mental picture.  You can largely reuse the one you had about CVS.
> (There are some _new_ bits to get used to, especially when you decide
> to work on a significant new feature on a local branch.  But you don't
> need to struggle with these new bits until you actually decide to do
> such work.)

In all the docs I've read, there's never been much of a separation
between branches and checked-out working copies, and that's caused me a
lot of confusion.

> To reuse your CVS mental model, just use the "Doing Quick Fixes"
> workflow as it is described on the wiki.  Note that the recommended
> workflow was changed since you have read it, because it no longer
> proposes to use a separate local branch, but rather either do it in the
> trunk or in a branch that is bound to upstream, exactly like the trunk
> is.

Ah.  That will be why my setup doesn't match the wiki one any more.  ;-)

> > I don't find the bazaar documentation much help in forming such a
> > mental picture.

> That's true, unfortunately.  Feel free to ask questions here, though.

My mistake was I tried to move my changes from "quickfixes" to "trunk"
using "bzr merge".  'bzr help merge' doesn't say what is merged with what
where, sadly.

I think what I really want is 'bzr push'.  Is this correct?  The
documentation for 'bzr push' is not helpful.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Help me unstick my bzr, please.

[Juanma Barranquero]

On Sat, Jan 16, 2010 at 22:27, Alan Mackenzie <acm@muc.de> wrote:

> My mistake was I tried to move my changes from "quickfixes" to "trunk"
> using "bzr merge".  'bzr help merge' doesn't say what is merged with what
> where, sadly.

You said:

> I attempt to merge the change into my "trunk" branch by doing this:
>
>   ~/emacs/emacs.bzr/quickfixes$ bzr merge

which is the wrong way. If you want to merge changes *from* a branch
*into* trunk, you should do

  cd trunk
  bzr update                # to make sure trunk is up to date
  bzr merge ../quickfixes   # or the task branch, etc.

> I think what I really want is 'bzr push'.  Is this correct?

No.

> The documentation for 'bzr push' is not helpful.

Sadly true.

    Juanma

Re: Help me unstick my bzr, please.

[Alan Mackenzie]

Hi, Giorgos,

Thanks for all the explanation!

On Sat, Jan 16, 2010 at 04:37:24AM +0200, Giorgos Keramidas wrote:
> On Fri, 15 Jan 2010 22:27:24 +0000, Alan Mackenzie <acm@muc.de> wrote:
> > Hi, Emacs,

> > I've been struggling with this fine distributed version control
> > system for over a week now.  My trouble is that I have no mental
> > picture of what the main bits are in bzr and what the relationships
> > between them are.  I don't find the bazaar documentation much help
> > in forming such a mental picture.

> > Specific problem: I have just fixed a bug in my "quickfixes" branch.
> > This involved changing a single C file and .../src/ChangeLog.  I
> > attempt to merge the change into my "trunk" branch by doing this:

> >     ~/emacs/emacs.bzr/quickfixes$ bzr merge

> > I get this error message:

> >     bzr: ERROR: Working tree "/home/acm/emacs/emacs.bzr/quickfixes/" has
> >     uncommitted changes (See bzr status).

> > When I execute bzr status, it gives me a list of ~55 allegedly modified
> > files, finishing up with:

> >     pending merge tips: (use -v to see all merge revisions)
> >       Jan D. 2010-01-06 [merge] Fix slowdown and wrong font choosed by XSETTINGS...

> > Would somebody please tell me what I might have done to make bzr think
> > I've got 55 modified files?  How might I recover from this?

> The "pending merge" message means that in the past (before you made the
> quick fix to the two files) you did:

>     bzr merge

OK, that's quite likely.  Am I right believing that 'bzr merge' pulls in
any changes in the current branch's parent?

> This pulled stuff from the local trunk branch, and merged it with your
> local quickfixes branch.  But you have to also run "bzr commit" to
> complete the fix.  You didn't at the time, so the quickfixes branch
> remains in a "the merge has locally finished but it is uncommitted"
> state.

> I think the easiest way to revert your local "quickfixes" branch to a
> known & sane state is something like:

>     1. Keep a backup of the two files you modified.
>     2. Wipe the local quickfixes branch.
>     3. Re-create the quickfixes from trunk.
>     4. Overwre the two files in the new quickfixes branch.
>     5. Use "bzr diff" to inspect the changes.
>     6. Commit them with "bzr commit".

Do I want to revert it?  I don't think I do.  If I just do "bzr commit"
in my .../quickfixes, that should leave it in a consistent state,
shouldn't it? 

After that, I want to get my changes from .../quickfixes copied over to
.../trunk.  Is 'bzr push' the way to do this?

> HTH,

It did, very much!

> Giorgos

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Help me unstick my bzr, please.

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Sorry, I don't understand what you mean by ``appear to be mainline''
 > and by ``commits [...] to be a feature branch''.  Can you elaborate?

I suspect the approach you propose will have the following appearance
in bzr log:

$ bzr log
2       acm made a small change to CC mode
1       rms made a small change to RMail
$ bzr log -n0
2       acm made a small change to CC mode
  1.3     eli made a small change to the MSDOS Makefile.in
  1.2     cyd released Emacs 23.2
  1.1     dak added a node to Info
1       rms made a small change to RMail
$

Very likely to happen in acm's mirror branch, and I believe that this
would propagate to the main repository when he pushes.  It is
*definitely possible* for this to happen.  Whether or not it *will*
happen depends on exactly what the state of acm's branch is and how he
goes about fixing it up, merging to trunk, and pushing to Savannah.

If it happens and gets pushed, it is repairable, of course, but only
at the cost of rebasing a published branch.

Simple unsticking with 'bzr shelve' [was: Help me unstick ...]

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > 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.

The biggest problem with the bad state is that it is not obvious what
to do about it.  Documentation is needed.

Actually (sorry for not remembering this earlier because it is
TOOWTDI) ...

Just use "bzr shelve".  Suppose the files Alan changed are cc-foo.el
and cc-bar.el, and nothing in the 55 files in the merge touched them.

$ bzr shelve cc-foo.el cc-bar.el
$ bzr resolve --all
$ bzr update                # may not be needed but shouldn't hurt

should DTRT, and now Alan can do "bzr log -n0" and "bzr status" to
check for sanity (yes, Alan, you *can* trust your intuition here), and
if things look OK,

$ bzr unshelve
$ bzr commit -m "Killer feature added to CC Mode!"

and push as appropriate for his branch layout.

See "bzr help shelve" for details and caveats on use of the shelf.

Re: Help me unstick my bzr, please.

[Giorgos Keramidas]

On Sat, 16 Jan 2010 21:38:21 +0000, Alan Mackenzie <acm@muc.de> wrote:
> On Sat, Jan 16, 2010 at 04:37:24AM +0200, Giorgos Keramidas wrote:
>> On Fri, 15 Jan 2010 22:27:24 +0000, Alan Mackenzie <acm@muc.de> wrote:
>> > When I execute bzr status, it gives me a list of ~55 allegedly modified
>> > files, finishing up with:
>
>> >     pending merge tips: (use -v to see all merge revisions)
>> >       Jan D. 2010-01-06 [merge] Fix slowdown and wrong font choosed by XSETTINGS...
>
>> > Would somebody please tell me what I might have done to make bzr think
>> > I've got 55 modified files?  How might I recover from this?
>
>> The "pending merge" message means that in the past (before you made the
>> quick fix to the two files) you did:
>
>>     bzr merge
>
> OK, that's quite likely.  Am I right believing that 'bzr merge' pulls in
> any changes in the current branch's parent?

Hi Alan,

Yes, you are right.  "bzr merge" pulls changes from the parent branch.
This means that if you have committed local changes in 'quickfixes', the
history DAG of the quickfixes branch looks like this:

    ... o --- o --- o --- X (local change)
                     \
                      `----- o --- o --- Y (last parent branch changeset)

After "bzr merge" has pulled the changes at the bottom of this history
DAG it then tries to merge these changes with the state of the current
working directory.

The final result of a successful "bzr merge" command is then a working
directory that refers to _both_ the parent changes (your "X" local
change and the latest changeset in the parent branch (Y in this case).

Before you "bzr commit" a merged state the history DAG is

    ... o --- o --- o --- X =================== W
                     \                         //
                      `----- o --- o --- Y ===//

where the double lines represent the uncommitted state of the "merge"
you just performed.  This merge is *not* recorded into the metadata of
the branch yet, so you have to follow "bzr merge" with "bzr commit" to
complete this operation:

    ... o --- o --- o --- X ------------------- W
                     \                         /
                      `----- o --- o --- Y ---/

This will record the locally merged files as a new changeset and you
will be able to "bzr push" to the parent branch.  The "bzr push" will
then be able to send the X and W changesets to the parent branch.

In terms similar to what CVS does, the two commands -- "bzr merge" and
"bzr commit" --- perform operations similar to "cvs update" and "cvs
commit".

  * The "bzr merge" command pulls changes from the parent branch, stores
    them in the .bzr metadata of the local branch and also tries to
    apply the changes it just pulled to the files of the working
    directory.  Conflicts may arise at this point, precisely as they did
    for "cvs update".

  * When all conflicts are resolved, "bzr commit" stores the resolved
    state of all files in the .bzr/ area of the local branch.  A "push"
    can then send them to the parent branch.

>> I think the easiest way to revert your local "quickfixes" branch to a
>> known & sane state is something like:
>>
>>     1. Keep a backup of the two files you modified.
>>     2. Wipe the local quickfixes branch.
>>     3. Re-create the quickfixes from trunk.
>>     4. Overwre the two files in the new quickfixes branch.
>>     5. Use "bzr diff" to inspect the changes.
>>     6. Commit them with "bzr commit".
>
> Do I want to revert it?  I don't think I do.  If I just do "bzr
> commit" in my .../quickfixes, that should leave it in a consistent
> state, shouldn't it?
>
> After that, I want to get my changes from .../quickfixes copied over
> to .../trunk.  Is 'bzr push' the way to do this?

The choice of "revert" was a poor one.  I didn't mean "revert" as in
"lose your local changes to the two files you edited manually, but more
like "finish the pending merge and allow more commits to this branch".

Stephen J. Turnbull has posted an easier method for restoring sanity to
the quickfixes branch, using "bzr shelve".  Now that I have read about
it and tried it in a small sample branch at home, I think it's probably
better to avoid trashing the quickfixes branch and use Stephen's
recommendation.