Re: merge conlict?

[Stefan Monnier]

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

There is no proposal.  I was just trying to resolve a confusion in the
discussion (and clearly failed to do so).

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

Who cares: it just describes my workflow, nothing more.  If/when I feel
like such a workflow should be turned into a convention that other
people should follow, rest assured that I'll do so in a separate thread.

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

If you go back in time, you'll see that I've generally been on the
"don't even bother to clean up the ChangeLog" side of the discussion.


        Stefan