Message ID | pull.1336.v2.git.1661376112.gitgitgadget@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | built-in add -p: support diff-so-fancy better | expand |
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > Philippe Blain reported in > https://lore.kernel.org/git/ecf6f5be-22ca-299f-a8f1-bda38e5ca246@gmail.com > that there is a problem when running the built-in version of git add -p with > diff-so-fancy [https://github.com/so-fancy/diff-so-fancy] as diff colorizer. > The symptom is this: > > error: could not parse colored hunk header '?[36m?[1m?[38;5;13m@ file:1 @?[1m?[0m' > > > This patch series addresses that and should fix > https://github.com/so-fancy/diff-so-fancy/issues/437 > > Changes since v1: > > * Added a commit to ignore dirty submodules just like the Perl version > does. Thanks, all. Will queue, but it may miss this afternoon's integration I am preparing right now for pushing out.
Hi Dscho, Le 2022-08-24 à 17:21, Johannes Schindelin via GitGitGadget a écrit : > Philippe Blain reported in > https://lore.kernel.org/git/ecf6f5be-22ca-299f-a8f1-bda38e5ca246@gmail.com > that there is a problem when running the built-in version of git add -p with > diff-so-fancy [https://github.com/so-fancy/diff-so-fancy] as diff colorizer. > The symptom is this: > > error: could not parse colored hunk header '?[36m?[1m?[38;5;13m@ file:1 @?[1m?[0m' > > > This patch series addresses that and should fix > https://github.com/so-fancy/diff-so-fancy/issues/437 > > Changes since v1: > > * Added a commit to ignore dirty submodules just like the Perl version > does. > > Johannes Schindelin (4): > t3701: redefine what is "bogus" output of a diff filter > add -p: gracefully ignore unparseable hunk headers in colored diffs > add -p: handle `diff-so-fancy`'s hunk headers better > add -p: ignore dirty submodules > > add-patch.c | 24 ++++++++++++++---------- > t/t3701-add-interactive.sh | 24 +++++++++++++++++++++++- > 2 files changed, 37 insertions(+), 11 deletions(-) > > > base-commit: 795ea8776befc95ea2becd8020c7a284677b4161 > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1336%2Fdscho%2Fdiff-so-fancy-v2 > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1336/dscho/diff-so-fancy-v2 > Pull-Request: https://github.com/gitgitgadget/git/pull/1336 > > Range-diff vs v1: > > 1: 74ab50eeb1c = 1: 74ab50eeb1c t3701: redefine what is "bogus" output of a diff filter > 2: b07f85a0359 = 2: b07f85a0359 add -p: gracefully ignore unparseable hunk headers in colored diffs > 3: 9dac9f74d2e = 3: 9dac9f74d2e add -p: handle `diff-so-fancy`'s hunk headers better > -: ----------- > 4: 540ce27c38a add -p: ignore dirty submodules > Thanks, 4/4 fixes the mismatched output bug. Just after I sent my last email, I asked myself "but why does 'git add -p' presents dirty submodule to the user, as they can't be staged?" :) A small question about 2/4, any reason why you did not use a "Reported-by:" trailer ? Not that I care that much, but I think using such a trailer is more standard, and makes for easier statistics as it's more parseable :) Thanks again for the quick fixes, Philippe.
Hi Philippe, On Wed, 24 Aug 2022, Philippe Blain wrote: > Le 2022-08-24 à 17:21, Johannes Schindelin via GitGitGadget a écrit : > > Philippe Blain reported in > > https://lore.kernel.org/git/ecf6f5be-22ca-299f-a8f1-bda38e5ca246@gmail.com > > that there is a problem when running the built-in version of git add -p with > > diff-so-fancy [https://github.com/so-fancy/diff-so-fancy] as diff colorizer. > > The symptom is this: > > > > error: could not parse colored hunk header '?[36m?[1m?[38;5;13m@ file:1 @?[1m?[0m' > > > > > > This patch series addresses that and should fix > > https://github.com/so-fancy/diff-so-fancy/issues/437 > > > > Changes since v1: > > > > * Added a commit to ignore dirty submodules just like the Perl version > > does. > > > > Johannes Schindelin (4): > > t3701: redefine what is "bogus" output of a diff filter > > add -p: gracefully ignore unparseable hunk headers in colored diffs > > add -p: handle `diff-so-fancy`'s hunk headers better > > add -p: ignore dirty submodules > > > > add-patch.c | 24 ++++++++++++++---------- > > t/t3701-add-interactive.sh | 24 +++++++++++++++++++++++- > > 2 files changed, 37 insertions(+), 11 deletions(-) > > > > > > base-commit: 795ea8776befc95ea2becd8020c7a284677b4161 > > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1336%2Fdscho%2Fdiff-so-fancy-v2 > > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1336/dscho/diff-so-fancy-v2 > > Pull-Request: https://github.com/gitgitgadget/git/pull/1336 > > > > Range-diff vs v1: > > > > 1: 74ab50eeb1c = 1: 74ab50eeb1c t3701: redefine what is "bogus" output of a diff filter > > 2: b07f85a0359 = 2: b07f85a0359 add -p: gracefully ignore unparseable hunk headers in colored diffs > > 3: 9dac9f74d2e = 3: 9dac9f74d2e add -p: handle `diff-so-fancy`'s hunk headers better > > -: ----------- > 4: 540ce27c38a add -p: ignore dirty submodules > > > > Thanks, 4/4 fixes the mismatched output bug. Just after I sent my last email, > I asked myself "but why does 'git add -p' presents dirty submodule to the user, > as they can't be staged?" :) > > A small question about 2/4, any reason why you did not use a "Reported-by:" > trailer ? Not that I care that much, but I think using such a trailer is more > standard, and makes for easier statistics as it's more parseable :) Good suggestion. How about adding your review? I'll then add a "Reviewed-by:" trailer, too ;-) Ciao, Dscho
Hi Dscho, Le 2022-08-26 à 07:43, Johannes Schindelin a écrit : > Hi Philippe, > > On Wed, 24 Aug 2022, Philippe Blain wrote: > >> Le 2022-08-24 à 17:21, Johannes Schindelin via GitGitGadget a écrit : >>> Philippe Blain reported in >>> https://lore.kernel.org/git/ecf6f5be-22ca-299f-a8f1-bda38e5ca246@gmail.com >>> that there is a problem when running the built-in version of git add -p with >>> diff-so-fancy [https://github.com/so-fancy/diff-so-fancy] as diff colorizer. >>> The symptom is this: >>> >>> error: could not parse colored hunk header '?[36m?[1m?[38;5;13m@ file:1 @?[1m?[0m' >>> >>> >>> This patch series addresses that and should fix >>> https://github.com/so-fancy/diff-so-fancy/issues/437 >>> >>> Changes since v1: >>> >>> * Added a commit to ignore dirty submodules just like the Perl version >>> does. >>> >>> Johannes Schindelin (4): >>> t3701: redefine what is "bogus" output of a diff filter >>> add -p: gracefully ignore unparseable hunk headers in colored diffs >>> add -p: handle `diff-so-fancy`'s hunk headers better >>> add -p: ignore dirty submodules >>> >>> add-patch.c | 24 ++++++++++++++---------- >>> t/t3701-add-interactive.sh | 24 +++++++++++++++++++++++- >>> 2 files changed, 37 insertions(+), 11 deletions(-) >>> >>> >>> base-commit: 795ea8776befc95ea2becd8020c7a284677b4161 >>> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1336%2Fdscho%2Fdiff-so-fancy-v2 >>> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1336/dscho/diff-so-fancy-v2 >>> Pull-Request: https://github.com/gitgitgadget/git/pull/1336 >>> >>> Range-diff vs v1: >>> >>> 1: 74ab50eeb1c = 1: 74ab50eeb1c t3701: redefine what is "bogus" output of a diff filter >>> 2: b07f85a0359 = 2: b07f85a0359 add -p: gracefully ignore unparseable hunk headers in colored diffs >>> 3: 9dac9f74d2e = 3: 9dac9f74d2e add -p: handle `diff-so-fancy`'s hunk headers better >>> -: ----------- > 4: 540ce27c38a add -p: ignore dirty submodules >>> >> >> Thanks, 4/4 fixes the mismatched output bug. Just after I sent my last email, >> I asked myself "but why does 'git add -p' presents dirty submodule to the user, >> as they can't be staged?" :) >> >> A small question about 2/4, any reason why you did not use a "Reported-by:" >> trailer ? Not that I care that much, but I think using such a trailer is more >> standard, and makes for easier statistics as it's more parseable :) > > Good suggestion. > > How about adding your review? I'll then add a "Reviewed-by:" trailer, too > ;-) I won't have time to look at the code changes themselves, and I've never looked at the builtin add -p code (nor the original Perl one!) so it would take some time. Cheers, Philippe.