merge should show base always, or at least configurably

[Jelmer Vernooij]

It would be nice if Bazaar could provide the contents of a conflicting text region as they were in the base revision in addition to the contents in the THIS and OTHER revisions (where relevant). This can often be useful when resolving merge conflicts.

[Martin Pool (mbp)]

merge or remerge --show-base?

Perhaps this should be made more obvious in documentation or turned on by default when possible?

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jelmer Vernooij wrote:
> Public bug reported:
>
> It would be nice if Bazaar could provide the contents of a conflicting
> text region as they were in the base revision in addition to the
> contents in the THIS and OTHER revisions (where relevant). This can
> often be useful when resolving merge conflicts.
>
> ** Affects: bzr
> Importance: Undecided
> Status: New
>

You mean 'bzr merge --show-base' ?

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvFM8gACgkQJdeBCYSNAAMLfwCg0Y9G7UnyOz5vCG+PNrU7V3bG
HpEAnR8mXhanTy7Fe8/j/bmEsqDvwFkG
=RUs4
-----END PGP SIGNATURE-----

[Jelmer Vernooij (jelmer)]

On Wed, 2010-04-14 at 00:37 +0000, Martin Pool wrote:
> merge or remerge --show-base?
>
> Perhaps this should be made more obvious in documentation or turned on
> by default when possible?
I was under the impression that this would just print the revision
number of the base revision. Obviously I was mistaken. :-)

It would be nice to have a configuration option for this, indeed
possibly defaulting to default. I can't think of a situation where I
would *not* want this.

Cheers,

Jelmer

[Martin Pool (mbp)]

An alias is not a good workaround because it clashes with --weave.

It sounds like the help needs to be better too.

[Aaron Bentley (abentley)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/14/2010 12:03 PM, Jelmer Vernooij wrote:

> It would be nice to have a configuration option for this, indeed
> possibly defaulting to default. I can't think of a situation where I
> would *not* want this.

You might not want it because it is incompatible with --reprocess, and
you might want that instead.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvXnZcACgkQ0F+nu1YWqI1s4QCfW7pcJMZjsjWJI/T3Yalu2eSQ
wZsAn0iFjV4jJlLXn/db5w6e2h5y7YHe
=Z7gS
-----END PGP SIGNATURE-----

[Robert Collins (lifeless)]

Would having --reprocess turn it off be sufficient?

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> Would having --reprocess turn it off be sufficient?
>

At the moment we default to --reprocess being on, because it generally
provides a more sane region of conflict. If you supply --show-base then
we disable --reprocess. If you supply both, then it complains.

In general, I find --reprocess more useful than --show-base, which is
why we defaulted that way.

The specifics as to why --reprocess and --show-base are incompatible.
Specifically, --reprocess finds common regions in THIS and OTHER in the
conflicted areas. But those are not common to BASE otherwise it would
not have conflicted.

Imagine:

BASE: abc
THIS: adefc
OTHER: axefyc

In this case merge will give:

a
<<<<
d
e
f
=====
x
e
f
y
>>>>>
c

- --reprocess will give

a
<<<<
d
=====
x
>>>>>
e
f
<<<<<
=====
y
>>>>>
c

Show base would give:
a
<<<<
d
e
f
|||||
b
=====
x
e
f
y
>>>>>
c

But where does 'b' go after --reprocess?

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvYpKUACgkQJdeBCYSNAAP0AgCgsYFud7QDminijJXrNLBMsC4B
wxsAn2PQy4VVxd/Oc7gS31AZ9Jt9w8a6
=yWua
-----END PGP SIGNATURE-----

[Vincent Ladeuil (vila)]

'b' disappears because it's not involved in a conflict anymore.

So --reprocess --show-base could give:

a
<<<<
d
|||||
=====
x
>>>>>
e
f
<<<<<
|||||
=====
y
>>>>>
c

[Stefan Monnier (monnier)]

FWIW, I much prefer the --show-base output because it's easy to go from the --show-base output to the --reprocess output (e.g. you can do that with Emacs's smerge-mode), whereas the reverse is simply impossible (that is, without doing the equivalent of re-merging).