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