Thanks for posting this series. I had not read it in full before.
The series is very long and it is hard to make certain it does not
introduce regressions. Here is my idea for working around this: the
idea is to grab patches from the series to form short, independently
justifiable mini-series. Once most of the functional changes are
merged, it should be a lot easier to evaluate the core code change
that makes setup more brittle (which I like a lot).
What do you think? Is it worth the trouble?
Here’s an example mini-series. Patch 1 adds a test case for
some weird git -p behavior. Patch 2 fixes it.
Jonathan Nieder (1):
t7006: test an edge case for git --paginate
Nguyễn Thái Ngọc Duy (1):
builtins: do not commit pager choice early
git.c | 1 -
t/t7006-pager.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 1 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html