Re: Confusing "bzr log" as result of merges

[Óscar Fuentes]

Eli Zaretskii <address@hidden> 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.