Tue, 30 Aug 2016 14:10:16 -0700 flake8: fix E127 style
Sean Farley <sean@farley.io> [Tue, 30 Aug 2016 14:10:16 -0700] rev 2004
flake8: fix E127 style
Tue, 30 Aug 2016 14:12:49 -0700 flake8: fix W391 style
Sean Farley <sean@farley.io> [Tue, 30 Aug 2016 14:12:49 -0700] rev 2003
flake8: fix W391 style
Tue, 30 Aug 2016 14:05:36 -0700 tests: add flake8 check
Sean Farley <sean@farley.io> [Tue, 30 Aug 2016 14:05:36 -0700] rev 2002
tests: add flake8 check This test will hopefully help prevent style errors. To be determined: which errors / warnings to ignore?
Sun, 15 May 2016 22:23:16 -0300 flake8: add file for rules to ignore
Sean Farley <sean@farley.io> [Sun, 15 May 2016 22:23:16 -0300] rev 2001
flake8: add file for rules to ignore This will help prevent users that have an editor with flake8 capabilities from fixing linter errors for rules that are not wanted by the project. Initially, this ignore list includes everything in the project that violates pep8. I'll try to ween this list down to something a little more manageable.
Fri, 26 Aug 2016 16:57:45 +0000 init: guard _namemap with repo.topics (issue5351)
timeless@gmail.com [Fri, 26 Aug 2016 16:57:45 +0000] rev 2000
init: guard _namemap with repo.topics (issue5351) This prevents reading extra data on all repo commits when there is no topic for a given name. _namemap is called a lot, and it is often called for commit shas -- which should pretty much never be names of topics...
Fri, 26 Aug 2016 16:52:02 +0000 init: cache repo.topics
timeless@gmail.com [Fri, 26 Aug 2016 16:52:02 +0000] rev 1999
init: cache repo.topics
Fri, 26 Aug 2016 21:57:48 +0200 stack: add warning about multiple heads
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 26 Aug 2016 21:57:48 +0200] rev 1998
stack: add warning about multiple heads This seems a good spot to nudge people toward reducing there head count.
Fri, 26 Aug 2016 14:55:58 +0200 stack: add some behind information
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 26 Aug 2016 14:55:58 +0200] rev 1997
stack: add some behind information This is the next useful thing after branch
Fri, 26 Aug 2016 14:23:31 +0200 stack: add some basic branch information
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 26 Aug 2016 14:23:31 +0200] rev 1996
stack: add some basic branch information In the same spirit as knowing the topic you are on, having some branch data seem useful (yet, this smell a bit like summary)
Fri, 26 Aug 2016 14:14:04 +0200 stack: add some header with the topic name
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 26 Aug 2016 14:14:04 +0200] rev 1995
stack: add some header with the topic name This is the first step of a move to add more data about a stack in the command output.
Fri, 26 Aug 2016 14:58:18 +0200 test: add testing of stack output in 'stack-data' test.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 26 Aug 2016 14:58:18 +0200] rev 1994
test: add testing of stack output in 'stack-data' test. We are going to display common information, so we reuse test case.
Fri, 26 Aug 2016 14:58:49 +0200 test: rename 'list' test to 'stack-data'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 26 Aug 2016 14:58:49 +0200] rev 1993
test: rename 'list' test to 'stack-data' We are about to add stack data information to 'hg stack'. As we'll re-use the test data creating the 'test-topic-list.t' we need to rename it first to embrace its new semantic.
Fri, 26 Aug 2016 12:58:16 +0200 stack: also dim bases
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 26 Aug 2016 12:58:16 +0200] rev 1992
stack: also dim bases Now that they may have index it seems better to have a stronger marking for bases.
Fri, 26 Aug 2016 12:52:06 +0200 stack: reusing the index number in base when applicable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 26 Aug 2016 12:52:06 +0200] rev 1991
stack: reusing the index number in base when applicable This clarify the branching when it is easy to track back the branching point. This does not takes the evolution graph into account yet.
Fri, 26 Aug 2016 12:37:52 +0200 stack: extra argument validation logic outside of showstack
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 26 Aug 2016 12:37:52 +0200] rev 1990
stack: extra argument validation logic outside of showstack It seems sensible keep the 'showstack' function purely about actually displaying and existing stack.
(0) -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 tip