bzr update: Use (G) instead of (M) on merge?

[Matteo Settenvini]

Il giorno dom, 02/09/2007 alle 16.04 +0300, Jari Aalto ha scritto:
> Running:
> 
>     bzr update
> 
> Produces modified results:
> 
>      M  changelog
>      M  control.in
>      M  rules
>     All changes applied successfully.
>     Updated to revision 176.
> 
> For me this is a little disorienting, since I'm actaully asking
> a merge from repository. Would it be possible that on
> 'update', the 'M' flags would show instead e.g. mer(G)ed:
> 
> 
>      G  changelog
>      G  control.in
>      G  rules
>     All changes applied successfully.
>     Updated to revision 176.
> 
> The (M) flags make me think I had locally modified files while I ran
> the command. That may sound silly, but that's the perception; I
> probably have strong association to "M" as being result of "bzr
> status".
>
> Jari
> 

I would rather purpose another semantics for "G". It'd make sense for me
to separate files that are modified for the first time within the merge,
to files that have local changes and are patched in the merged and thus
present new changes pending review (since patch and diff are clever up
until a certain point, and so changes from two different contributors
could not overlap in text but nevertheless produce unexpected results).

So, let's say I've a local tree where:

modified:
  M file.a
  M file.b
  M file.c

and then I merge another branch in mine, where file.b was modified and
didn't produce a conflict, and file.c was modified and produced a
conflict, and file.d was modified only in the branch I merged.

So, you'd get:

  M file.a
  G file.b
  C file.c
  M file.d

This could help you identify potential problems before committing the
merge. file.a would be probably okay since it contains only my changes;
equally file.d should be okay since it contains only someone other's
changes (if you trust the committer :-)). 
file.c is conflicting and thus must be edited before committing, while
file.b ideally needs review since subtle problems could have crept in
with the merge.

Anyway, that's just my 2¢, not sure if they're right.

Cheers,
-- 
Matteo Settenvini
FSF Associated Member
Email : matteo at member.fsf.org


-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(-) s+:- a-- C++ UL+++ 
P?>++ L+++>$ E+>+++ W+++ N++ o? 
w--- O- M++ PS++ PE- Y+>++ 
PGP+++ t+ 5 X- R tv-- b+++ DI+ 
D++ G++ e h+ r-- y?
------END GEEK CODE BLOCK------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio
	firmata digitalmente
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070902/03ad1a4a/attachment.pgp