[RFC] Conflicts handling in status command
Aaron Bentley
aaron.bentley at utoronto.ca
Mon Jul 23 12:27:14 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Guillermo Gonzalez wrote:
> Aaron Bentley wrote:
>
> [snip]
>> The first column is reserved for +-R
>> (add/remove/rename). Putting C there would interfere with that. You'd
>> have to add another column. Putting text after the filename would make
>> it hard for scripts to parse the output.
>>
>
> I understand the problem with the first column (+-R), is there any problem
> to add a new column?
Just the desire to keep things simple. It's not an absolute rule,
obviously.
> About the text after the filename, the conflicts are showed as "text
> conflict in <filename>".
Actually, there are eight kinds of conflicts.
Single-path conflicts
=====================
text conflict
contents conflict
parent loop
unversioned parent
missing parent
deleting parent
Multi-path conflicts
=====================
duplicate id
duplicate filename
> Following the same pattern the proposed output could be modified to
> something like:
> M C COPYING has text conflicts
- - Multiple conflicts may appy to a single file.
- - The multi-path conflicts don't fit your template at all.
- - If the file has been renamed, it's easy to see how you could run out
of space.
- - As I noted before, it makes it significantly harder for scripts to
parse the output.
> What other posibilities do you see?
> (I'ld really like to know if this can be done)
I don't think what you're proposing makes sense.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGpJCB0F+nu1YWqI0RAsuvAJ9oMYO1g4V4VLUOTi7sqX9W7qAzJACfRcdD
WL8JkyIFmpPh1k8cTqSJvIw=
=TNJo
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list