g.brandl at gmx.net
Sat Jun 19 12:01:35 CEST 2010
Am 16.06.2010 21:53, schrieb Éric Araujo:
>> After using Mercurial in one project, I'm skeptical that this really
>> makes things simpler. I find it very hard to find out what changes a
>> specific clone has that I still need to integrate.
> There are commands to compare repositories: incoming and outgoing (read
> “hg help incoming”).
>> Also, when merging with conflicts, I find it very difficult to determine
>> whether I merged all the conflicts correctly (since the diff will show
>> all changes, not just the conflicts).
> I believe that’s a known bug. David Wolever is writing an extension to
> show only the diff against the automated merge, which would be more
> helpful: http://mercurial.selenic.com/wiki/MergediffExtension
> Bitbucket uses a similar algo to display merge diffs, I think.
I can understand that the behavior of mergediff is useful sometimes, but
the "default" one is what I want most of the time, for example when pulling
changes from a fork of Sphinx. I need to make sure that all "new code"
coming from the other branch integrates well with whatever may have changed
between the fork and the merge, and that includes locations without conflict.
Of course, one gets huge diffs soon, but there is always the possibility of
"splitting" merges, i.e. for a changeset graph (after pulling) looking
A1 A2 M
B1 B2 B3
where A are your changes and B the other branch's, and M the merge commit,
yout can merge a number of earlier versions so that it looks like this:
A1 A2 M1 M2
- / /
B1 B2 B3
If these merge points are chosen suitably (after logical units), this can
make merging much less painful.
Just a data point,
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
More information about the Catalog-SIG