Strategies for push/merge problem?

[Benjamin Smedberg]

Sean Kelley wrote:
> On Mon, Jul 14, 2008 at 5:16 PM, Doug Philips <dgou at mac.com> wrote:
>> On Monday, July 14, 2008, at 05:58PM, "Benjamin Smedberg" indited:
>>> Johannes Stezenbach wrote:
>>> It's a source of complaint, but not overwhelming. Some people are content to
>>> do a merge; others really object to history cluttering and spend time
>>> rebasing the commit forward, either manually or with MQ.
>> Yes, it takes effort to make the history something that it is not.
>> The merges show just where things went parallel and how they were merged.
>> rebasing makes believe that one thing happened after another.
>> Since that isn't actually what happened, work has to be spent re-writing history. :)
> 
> I personally don't have a problem with history that shows the merges
> and the mixed development.  I am too busy to rewrite history  :-)

Yes, but for a project with thousands of active developers, merges are 
mentally much more complex. What most of our developers care about is the 
history of what our tinderboxes built, which was "the tip of 
mozilla-central". When branch/merges are pushed, it's not always clear where 
mozilla-central was, and reading diffs between revisions becomes more 
complicated.

We have work underway to remedy this situation, see e.g. 
http://developer.mozilla.org/en/docs/Mercurial/Desired_Features#hgweb_requirements

This display form collects whatever changes happen in a push into a single 
item, and lets you diff between the tips. I think when this work is 
completed, people will worry less about pushing branch/merges. Until that 
time, they are dealing with a situation that is more confusing than our 
previous CVS+bonsai workflow.

--BDS