Re: merge conlict?

[Karl Fogel <kfogel@red-bean.com>]

Eli Zaretskii <eliz@gnu.org> writes:
>> 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.

I haven't been able to follow this entire thread, but: why doesn't the
recommended workflow suffice?

Is the problem that some people are saying that all the internal commits
on your local branch should be clean & buildable & lint-free, in
addition to the final merge being similarly clean?

If so, I think that would be an unreasonable expectation, and not one
I've seen other projects enforce.

The final merge needs to be of publishable quality, of course -- it's
going on the mainline.  But the commits that led up to it?  That's
really up to the committer(s).  No one else ever has to build those
commits, after all.  Even if the local branch is published somewhere
independently, so others can participate in its development, the
developer(s) can determine what quality standards they want to uphold
pre-merge.  The Emacs project as a whole should just uphold quality on
its official branches, especially the mainline.

Or if that's not what the problem is here, then sorry for the noise.  I
want to help, if I can, but I simply can't keep up with threads this
large, so it's possible my response will be mis-aimed.

-Karl