Wed, 12 Nov 2014 22:07:31 -0800 context.status: avoid de- and reconstructing status tuple
Martin von Zweigbergk <martinvonz@google.com> [Wed, 12 Nov 2014 22:07:31 -0800] rev 23303
context.status: avoid de- and reconstructing status tuple We can just modify the status tuple we got from dirstate.status() instead of deconstructing it and constructing a new instance, thereby simplifying the code a little.
Wed, 12 Nov 2014 16:51:11 -0800 context.status: make _dirstatestatus() return an status tuple
Martin von Zweigbergk <martinvonz@google.com> [Wed, 12 Nov 2014 16:51:11 -0800] rev 23302
context.status: make _dirstatestatus() return an status tuple Letting _dirstatestatus() return an scmutil.status instance also means that _buildstatus() will always return such an instance, so we can remove the conversion from the call sites.
Wed, 12 Nov 2014 21:19:07 -0800 context.status: wipe deleted/unknown/ignored fields when reversed
Martin von Zweigbergk <martinvonz@google.com> [Wed, 12 Nov 2014 21:19:07 -0800] rev 23301
context.status: wipe deleted/unknown/ignored fields when reversed It makes no sense to request reverse status (i.e. changes from the working copy to its parent) and then look at the deleted, unknown or ignored fields. If you do, you would get the result from the forward status (changes from parent to the working copy). Instead of giving a nonsensical answer to a nonsensical question, it seems a little saner to return empty lists. It might be best if we could prevent the caller accessing these lists, but it's doubtful it's worth the trouble.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip