Moving to D

Walter Bright newshound2 at digitalmars.com
Sat Jan 8 01:18:22 PST 2011


Russel Winder wrote:
> Walter,
> 
> On Fri, 2011-01-07 at 10:54 -0800, Walter Bright wrote:
>> Russel Winder wrote:
>>>> One thing I would dearly like is to be able to merge branches using meld.
>>>>
>>>> http://meld.sourceforge.net/
>>> Why?
>> Because meld makes it easy to review, selectively merge, and do a bit of editing 
>> all in one go.
> 
> Hummm . . .  these days that is seen as being counter-productive to
> having a full and complete record  of the evolution of a project.  These
> days it is assumed that a reviewed changeset is committed as is and then
> further amendments made as a separate follow-up changeset.  A core
> factor here is of attribution and publicity of who did what.   By
> committing reviewed changesets before amending them, the originator of
> the changeset is noted as the author of the changeset in the history.
> As I understand the consequences of the above system, you are always
> shown as the committer of every change -- but I may just have got this
> wrong, I haven't actually looked at the DMD repository.

I never thought of that.


>>> Mercurial, Bazaar and Git all support a variety of three-way merge tools
>>> including meld, but the whole point of branching and merging is that you
>>> don't do it manually -- except in Subversion where merging branching
>>> remains a problem.
>> But I want to do it manually.
> 
> Clearly I don't understand your workflow.  When I used Subversion, its
> merge capabilities were effectively none -- and as I understand it,
> things have not got any better in reality despite all the publicity
> about new merge support.  So handling changesets from branches and
> elsewhere always had to be a manual activity.  Maintaining a truly
> correct history was effectively impossible.  Now with Bazaar, Mercurial
> and Git, merge is so crucial to the very essence of what these systems
> do that I cannot conceive of manually merging except to resolve actual
> conflicts.
> 
> Branch and merge is so trivially easy in all of Bazaar, Mercurial and
> Git, that it changes workflows.  Reviewing changesets is still a
> crucially important thing, but merging them should not be part of that
> process.

I never thought of it that way before.


>>> With Mercurial, Bazaar and Git, if you accept a changeset from a branch
>>> you jsut merge it, e.g.
>>>
>>> 	git merge some-feature-branch
>>>
>>> job done.  If you want to amend the changeset before committing to HEAD
>>> then create a feature branch, merge the incoming changeset to the
>>> feature branch, work on it till satisfied, merge to HEAD.
>>>
>>> The only time I used meld these days is to process merge conflicts, not
>>> to handle merging per se. 
>> I've always been highly suspicious of the auto-detection of a 3 way merge conflict.
> 
> I have always been highly suspicious that compilers can optimize my code
> better than I can ;-)

You should be!


More information about the Digitalmars-d mailing list