hg status and intermediate file changes

Jason Harris jason at jasonfharris.com
Thu Feb 24 09:15:05 CST 2011


On Feb 24, 2011, at 3:45 PM, Mads Kiilerich wrote:

> On 02/24/2011 03:13 PM, Jason Harris wrote:
>> but what was the answer to the main question in my previous email? Ie the answer to the question summarized by:
>> 
>>> So in conclusion, basically I can see *lots* of upside / use of status showing the differences between start and end revisions. What are the upsides / use of  status showing the intermediate changes?
> 
> Well ... I have shared my opinion and tried to explain, and now I don't have more to add ;-)
> 
> Stat shows manifest changes and is thus fast. Diff shows content changes and thus has to do significantly more work and is slower. I don't think it is a good idea to blur that distinction.


Thanks :)

Someone had of course previously had the compare in their in the past and so was doing the compare (it just isn't / wasn't functioning correctly...). (Tracing through lots and lots of peoples commits who have touched that code (looks like about 10 or so people) including Matt, etc. (I stopped tracing once I got back to revision 1616 which was 5 years ago.) In summary all the previous authors have all left the compare in there...

Sooo...  then only real upside of the current behavior is speed (In fact the speed wasn't there until you just submitted your patch right)? 

... But in that case

I am *all* for status being fast. MacHg is very speed dependent on the status command. However, isn't  the compare operation only ever done if the flags say that a change was done at some intermediate stage along the way? Thus assuming the relative number of files with changes in them will be typically a small number compared to the total number of files in the repository this compare cost will be comparatively small.

I would still argue that having a useful result here trumps speed... :)

Thanks,
   Jas


More information about the Mercurial-devel mailing list