about bzr status --short

[John Arbash Meinel]

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

Alexander Belchenko wrote:
> Today I try to use 'bzr status --short'. Very nice.
> 
> But I have some questions.
> 
> 1) Can we provide short name for option --short? May be -s?
> 
> 2) Status of working tree after merge with conflicts:
> 
>  M  NEWS
>  M  bzrlib/osutils.py
>  M  bzrlib/urlutils.py
>  M  bzrlib/tests/test_osutils.py
>  M  bzrlib/tests/test_urlutils.py
> ?   NEWS.BASE
> ?   NEWS.OTHER
> ?   NEWS.THIS
> C   Text conflict in NEWS
> P   Alexander Belchenko 2007-02-14 NEWS entry
> P.   Alexander Belchenko 2007-02-14 win98_abspath:
> P.   Alexander Belchenko 2007-02-14 Don't do normpath
> P.   Alexander Belchenko 2007-02-14 Reimplementation
> 
> ^-- Why we print 'C' on separate line? Only because we want to
> print 'Text conflicts in...'? It could make machine parsing
> is slightly harder, is not?
> Also note that 'P.' is not documented in help.
> I don't know is dot really needed?
> I think for machine parsing of this output it will be OK.
> When we do octopus merge there will be several heads with
> 'P' and then their parents, is it?
> Just tiny little note.
> 
> Alexander


Actually the 'C' is on a separate line mostly because it is computed in
a second pass. Similarly for '?' entries (unknowns are computed after
working tree files).

Also, you can have more conflict types than just Text conflict. For
example, if 2 people rename the same file you end up with a path conflict.

And I think binary files end up with a Content conflict, which isn't
quite the same as a Text conflict. (I think the former is "contents
differ", the latter knows more about specific lines that conflict).

I agree that P. should be documented in the help.

As far as machine parsing, C NEWS - Text Conflict
might be easier to parse. Or we could use different characters for text
conflicts versus content versus path conflicts. So you could have
something like

CT  NEWS
CP  Paths

I know we are trying to avoid re-using characters, so CT would work, but
I don't think we want CC and CP (content conflict, path conflict).

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF0yBpJdeBCYSNAAMRAu79AJ9AHwt0xEhLooXd5py3l2jzfULv5QCfbeie
v3/ENywnarTD2G1XtkmtC4U=
=oSiw
-----END PGP SIGNATURE-----