Re: merge conlict?

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Mon, 25 Jan 2010 21:02:40 -0500
> Cc: address@hidden
> 
> > Second, what you propose is quite a bit of work, and not of the trivial
> > kind.
> 
> I think what Andreas is talking about is not about your temporary local
> commits, but rather that before commit your changes into the trunk,
> you'll want to rework them into a set of clean logical patches.

Actually, no proposal that's even remotely close to being complete was
ever laid on the table.  Without such a proposal, this thread has long
ago degenerated into useless noise.

> My experience is indeed that Bzr helps me keep track of local changes
> and work on long-time branches, but usually when it gets time to install
> on the trunk, I really port the changes "by hand" rather than just ask
> Bzr to merge some (set of) change(s), so that I can clean them up (and
> often enough, update&improve them).  Many people use "rebase" for that
> clean up.

I agree with Óscar: this is a lot of potentially unnecessary work.

Put yourself in my shoes: in the bidi branch I have roughly 2-3
commits for each week since August 2009 (1-2 commits for merges from
mainline, and 1 more for the bidi changes themselves I did during that
weekend).  This sounds like not too much, but it accumulates over the
months; do your math.  Having to sift through all that when the time
comes to merge with the trunk is not my idea of efficient use of my
scarce resources.  Especially since I don't see the boost in utility
that would justify such an investment.  The need to clean up the
ChangeLog entries is already a PITA, but that is at least marginally
bearable (because most intermediate entries are simply deleted).

Changes that do not require more than a single commit and take less
than a day to develop and test I already make in the trunk directly,
so "quickies" are out of this picture, and I'm talking only about
feature branches that require several non-trivial commits over
relatively prolonged periods of time (several days or weeks).

Maybe people who can hack Emacs all day long can cope with this
additional load.  I cannot, and I'm not convinced I'm the only one in
this league.

Switching to Bazaar was advertised as a boon for occasional
contributors.  That is supposed to cover people who don't have a lot
of time to invest in overhead activities.  Now it somehow turns out
that developing with Bazaar is more work than it was with CVS?  So
what did we switch for? to allow some advanced to exotic workflows for
those who have unlimited time to begin with?  That simply doesn't make
any sense to me.

But in any case, until Someone(TM) writes up a proposal for merging
feature branches that can be made part of the workflow, any
intelligent and useful discussion of this issue is hardly possible,
IMO.