Re: Help me unstick my bzr, please.

[Giorgos Keramidas <keramida@ceid.upatras.gr>]

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.