[MERGE] status command analysis

[Martin Pool]

Martin Pool has voted +1 (conditional).
Status is now: Conditionally approved
Comment:
+Status shows several things in parallel (for the paths the user 
supplied mapped
+across the from and to tree, and any pending merges in the to tree).

It can also show:

* unknown files
* files with conflicts
* files with pending merges

which would not (?) normally be included when just listing changes 
between two trees.  The integration of path filtering with these needs 
to take these into account.

+Status shows several things in parallel (for the paths the user 
supplied mapped
+across the from and to tree, and any pending merges in the to tree).

+1. For paths which have the same kind in both trees and have content, 
read
+   that content or otherwise determine whether the content has changed. 
Using
+   our hash cache from the dirstate allows us to avoid reading the file 
in the
+   common case. There are alternative ways to achieve this - we could 
record
+   a pointer to a revision which contained this fileid with the current 
content
+   rather than storing the content's hash; but this seems to be a 
pointless
+   double-indirection unless we save enough storage in the working 
tree.

Another alternative, though it doesn't have to be mentioned here: if we 
wanted to remove the text hash from the dirstate, I imagine we would do 
this: record the mtime/ctime at which it was known to be the same as in 
the primary parent, if it ever was.  This would save some space, and 
save us needing to hash the working file other than at commit time.  On 
the other hand, it would mean that when a file was the same as in a 
secondary parent but different to the primary parent, we would always 
need to read it completely to discover that.


+
+- We should stat files in the same directory without reading or 
statting
+files in other directories.

Rephrase to: we should stat all the files in a particular directory 
before proceeding to another directory.  (If that's what you mean.)

+  larger win. This strongly suggests that path expansion and tree
+  difference generation should be linked in terms of API.
+

Agree.  Though this nexus needs to take into account that status reports 
on more than just tree differences.

For details, see: 
http://bundlebuggy.aaronbentley.com/request/%3C1183343578.18080.2.camel%40localhost.localdomain%3E