{"thread":{"id":"63367","subject":"Discussion for interactive --patch commands to get --unified support","startedAt":"2025-04-29T09:16:28Z","lastAt":"2025-05-02T18:36:24Z","messageCount":12,"participants":["Leon Michalak","Junio C Hamano","Jeff King","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"516943","messageId":"CAP9jKjGb-Rcr=RLJEzeFdtrekYM+qmHy+1T1fykU3n9cV4GhGw@mail.gmail.com","threadId":"63367","inReplyTo":null,"subject":"Discussion for interactive --patch commands to get --unified support","fromName":"Leon Michalak","fromEmail":"leonmichalak6@gmail.com","sentAt":"2025-04-29T09:16:15Z","receivedAt":"2025-04-29T09:16:28Z","isPatch":false,"sender":{"key":"leonmichalak6@gmail.com","avatar":"https://avatars.githubusercontent.com/u/63664402?v=4"},"body":"Hi everyone!\n\nI am a big fan of `git diff` with a custom `diff.context` setting to\nincrease the context lines (which also extends to other commands like\n`git show` which I really like). As well as this, I am also a frequent\nuser of `git add --patch` (and also the other interactive `--patch`\nvariants such as reset).\n\nAs I've grown to use and appreciate these features even more, I have\nnoticed and been bothered that `git add --patch` doesn't have a (easy)\nway of configuring how many context lines you see. There is a\nstackoverflow post\n(https://stackoverflow.com/questions/6711670/git-show-more-context-when-using-git-add-i-or-git-add-e)\nwhich mentions you can do `GIT_DIFF_OPTS=-u<number> git add -p` which\ndoes work however isn't very user friendly or convenient.\n\nIt would be great if it was possible to start a discussion how this\ncould be made better (and I would be happy to submit a patch if all is\ngood). Whilst brainstorming briefly, here are a few options I have\nthought of that could solve this pain point, some not mutually\nexclusive:\n- `-U<number>/--unified=<number>` command line options to the\ninteractive patch commands (all builtins who call `run_add_p`)\n- make `diff.context` setting extend to the interactive patch commands\n(not sure how a change like this would be welcomed considering it\ncould change users command outputs seemingly out of nowhere)\n- add an `interactive.context` setting that would work like the\nexisting `diff.context` setting but apply only to the interactive\npatch commands\n\nIs this feature something people would welcome, and what are your thoughts?\n\nThanks!\n"},{"id":"516966","messageId":"xmqq34dq7w3h.fsf@gitster.g","threadId":"63367","inReplyTo":"CAP9jKjGb-Rcr=RLJEzeFdtrekYM+qmHy+1T1fykU3n9cV4GhGw@mail.gmail.com","subject":"Re: Discussion for interactive --patch commands to get --unified support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-04-29T16:48:02Z","receivedAt":"2025-04-29T16:48:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Leon Michalak <leonmichalak6@gmail.com> writes:\n\n> As I've grown to use and appreciate these features even more, I have\n> noticed and been bothered that `git add --patch` doesn't have a (easy)\n> way of configuring how many context lines you see. There is a\n> stackoverflow post\n> (https://stackoverflow.com/questions/6711670/git-show-more-context-when-using-git-add-i-or-git-add-e)\n> which mentions you can do `GIT_DIFF_OPTS=-u<number> git add -p` which\n> does work however isn't very user friendly or convenient.\n\nIf it is only to specify how many context lines to ask for the diff\nmachinery when preparing the initial patch that is presented in the\n\"add -p\" UI, it should be fairly easy.\n\nI would expect that development of such a feature would progress\nroughly in the following order.\n\n - Define \"struct add_p_opt {}\" that has one \"unsigned int\" member,\n   which is the unified context length, probably in add-interactive.h;\n\n - Teach add-interactive.c:run_add_p() to take an extra parameter of\n   type \"struct add_p_opt *opt\";\n\n - Teach builtin/add.c to take -U<n> argument, make sure to make it\n   an error when '-p' or '-i' is not given and -U<n> is.  Pass it in\n   that new parameter when calling run_add_p() you modified above.\n\n - Do the same for builtin/{checkout,reset,stash}.c where they also\n   call run_add_p().\n\n - Add a new command (sits next to \"add untracked\", \"patch\", \"diff\",\n   etc.) to set -U<n> in add-interactive.c:run_add_i(), so that the\n   default context length of 3 can be overridden before choosing\n   \"patch\" or \"diff\" commands in \"git add -i\".\n\nBecause we generate diff once, and then let the end-user dice and\nslice freely, without keeping track of the correspondence between\nwhat the original diff looked like and the current diff that is a\nresult of end-user dicing and slicing, I think extending the context\nlength on demand (i.e. \"I started an 'add -p' session, chose a few\nhunks, edited a handful hunks, and then realized that this single\nhunk I want to see a bit more context\") is _significantly_ harder.\nThe current code structure is simply not designed for it.\n\nIt would take a significant rewrite to allow you to say \"OK, let me\nregenerate the diff with wider context (this is the easy part) and\nfind the hunk with larger context that corresponds with the hunk you\nare talking about (harder)\".\n"},{"id":"516991","messageId":"20250429220933.GC36727@coredump.intra.peff.net","threadId":"63367","inReplyTo":"CAP9jKjGb-Rcr=RLJEzeFdtrekYM+qmHy+1T1fykU3n9cV4GhGw@mail.gmail.com","subject":"Re: Discussion for interactive --patch commands to get --unified support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-04-29T22:09:33Z","receivedAt":"2025-04-29T22:09:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 29, 2025 at 10:16:15AM +0100, Leon Michalak wrote:\n\n> - make `diff.context` setting extend to the interactive patch commands\n> (not sure how a change like this would be welcomed considering it\n> could change users command outputs seemingly out of nowhere)\n> - add an `interactive.context` setting that would work like the\n> existing `diff.context` setting but apply only to the interactive\n> patch commands\n\nIn my opinion it would be fine to respect diff.context (and probably\ndiff.interhunkcontext[1]) by default. Though it does change the command\noutput, the interactive output is by definition user-facing, so we\nshouldn't be breaking scripts. And we already respect other porcelain\nlevel config like colorizing.\n\nI think the only reason we don't already do so is that the interactive\ncode is built around the plumbing commands, which conservatively avoid\nvarious config options. So the calling code has to explicitly check the\nconfig itself.\n\n-Peff\n\n[1] Looking at git_diff_ui_config(), which are all the options read by\n    porcelain git-diff but not by plumbing git-diff-files, etc, there\n    may be other config in the same boat. E.g., I'd guess that people\n    with diff.colormoved set would appreciate seeing that effect in the\n    colorized versions we show. But I think it is OK to just consider\n    diff.context for now, and see if anybody ever cares enough about\n    other options to look into them.\n"},{"id":"517000","messageId":"CAP9jKjF5suY6mx19knKwWAEHrTJ_meWhktOuMTFixq0hmFsjuA@mail.gmail.com","threadId":"63367","inReplyTo":"20250429220933.GC36727@coredump.intra.peff.net","subject":"Re: Discussion for interactive --patch commands to get --unified support","fromName":"Leon Michalak","fromEmail":"leonmichalak6@gmail.com","sentAt":"2025-04-30T08:04:46Z","receivedAt":"2025-04-30T08:05:00Z","isPatch":false,"sender":{"key":"leonmichalak6@gmail.com","avatar":"https://avatars.githubusercontent.com/u/63664402?v=4"},"body":"> If it is only to specify how many context lines to ask for the diff\n> machinery when preparing the initial patch that is presented in the\n> \"add -p\" UI, it should be fairly easy.\n\nThis is the intention, I personally don't have a need for changing\nhunk context *during* an interactive add and as you say, this looks to\nbe a big task.\n\n> I would expect that development of such a feature would progress\n> roughly in the following order.\n\nAs someone who has never contributed to (or even very familiar with)\nthe codebase, this is very helpful and I really appreciate it!\n\n> In my opinion it would be fine to respect diff.context (and probably\n> diff.interhunkcontext[1]) by default.\n\nI think this could work nicely and agree with this approach.\n\n> Looking at git_diff_ui_config(), which are all the options read by\n> porcelain git-diff but not by plumbing git-diff-files, etc, there\n> may be other config in the same boat. E.g., I'd guess that people\n> with diff.colormoved set would appreciate seeing that effect in the\n> colorized versions we show.\n\nAgreed. As you mention it, I recently discovered `diff.colormoved` and\nI'd welcome this to the `--patch` functionality, although I also agree\nthat it would make sense to take things one step at a time and it's\nnot necessary to batch anything else into this change.\n\nWith all that being said, I propose the following:\n- inheriting `diff.context` and `diff.interhunkcontext` as the\ndefaults for the various interactive/patch commands\n- be able to override these defaults on the command line with\n`-U<n>/--unified=<n>` and `--inter-hunk-context=<n>` respectively\n\nThese would cover both a \"permanent\" config that you wouldn't need to\nspecify every time when writing the command/s out, but also would\nprovide a way to override the individual built-ins as/when you want.\n\nYou guys obviously have better knowledge and experience with git\ndevelopment so it would be great to hear your feedback on this.\n\nThanks!\n\nOn Tue, 29 Apr 2025 at 23:09, Jeff King <peff@peff.net> wrote:\n>\n> On Tue, Apr 29, 2025 at 10:16:15AM +0100, Leon Michalak wrote:\n>\n> > - make `diff.context` setting extend to the interactive patch commands\n> > (not sure how a change like this would be welcomed considering it\n> > could change users command outputs seemingly out of nowhere)\n> > - add an `interactive.context` setting that would work like the\n> > existing `diff.context` setting but apply only to the interactive\n> > patch commands\n>\n> In my opinion it would be fine to respect diff.context (and probably\n> diff.interhunkcontext[1]) by default. Though it does change the command\n> output, the interactive output is by definition user-facing, so we\n> shouldn't be breaking scripts. And we already respect other porcelain\n> level config like colorizing.\n>\n> I think the only reason we don't already do so is that the interactive\n> code is built around the plumbing commands, which conservatively avoid\n> various config options. So the calling code has to explicitly check the\n> config itself.\n>\n> -Peff\n>\n> [1] Looking at git_diff_ui_config(), which are all the options read by\n>     porcelain git-diff but not by plumbing git-diff-files, etc, there\n>     may be other config in the same boat. E.g., I'd guess that people\n>     with diff.colormoved set would appreciate seeing that effect in the\n>     colorized versions we show. But I think it is OK to just consider\n>     diff.context for now, and see if anybody ever cares enough about\n>     other options to look into them.\n"},{"id":"517023","messageId":"xmqqo6wd3e7v.fsf@gitster.g","threadId":"63367","inReplyTo":"CAP9jKjF5suY6mx19knKwWAEHrTJ_meWhktOuMTFixq0hmFsjuA@mail.gmail.com","subject":"Re: Discussion for interactive --patch commands to get --unified support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-04-30T14:40:04Z","receivedAt":"2025-04-30T14:40:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Leon Michalak <leonmichalak6@gmail.com> writes:\n\n> With all that being said, I propose the following:\n> - inheriting `diff.context` and `diff.interhunkcontext` as the\n> defaults for the various interactive/patch commands\n> - be able to override these defaults on the command line with\n> `-U<n>/--unified=<n>` and `--inter-hunk-context=<n>` respectively\n\nI think the usage pattern when people use \"add -p\" and \"diff\" are\ndifferent (with \"add -p\", you get only one hunk at a time, and you\nmay want a bit wider context to avoid getting disoriented, for\nexample) and I agree that it may be useful to be able to specify\ndifferent context lengths for them, which the above should cover\nnicely.\n\n"},{"id":"517115","messageId":"3e38b7b4-eb6e-4af5-a5f6-f0d7ca4d32d6@gmail.com","threadId":"63367","inReplyTo":"20250429220933.GC36727@coredump.intra.peff.net","subject":"Re: Discussion for interactive --patch commands to get --unified support","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-05-02T14:33:01Z","receivedAt":"2025-05-02T14:33:21Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Leon and Jeff\n\nOn 29/04/2025 23:09, Jeff King wrote:\n> On Tue, Apr 29, 2025 at 10:16:15AM +0100, Leon Michalak wrote:\n> \n>> - make `diff.context` setting extend to the interactive patch commands\n>> (not sure how a change like this would be welcomed considering it\n>> could change users command outputs seemingly out of nowhere)\n>> - add an `interactive.context` setting that would work like the\n>> existing `diff.context` setting but apply only to the interactive\n>> patch commands\n> \n> In my opinion it would be fine to respect diff.context (and probably\n> diff.interhunkcontext[1]) by default. Though it does change the command\n> output, the interactive output is by definition user-facing, so we\n> shouldn't be breaking scripts. And we already respect other porcelain\n> level config like colorizing.\n\nI think that would be a good place to start and would be a useful \nimprovement on the status quo. To implement it one can copy what we do \nto respect diff.algorithm. I'm not sure it is worth the effort to \nsupport `git add -p -U <context>`. Being able to interactively change \nthe context as suggested elsewhere sounds more interesting to me but it \nwould be more work to implement as we'd have to regenerate the diff each \ntime.\n\nBest Wishes\n\nPhillip\n\n> I think the only reason we don't already do so is that the interactive\n> code is built around the plumbing commands, which conservatively avoid\n> various config options. So the calling code has to explicitly check the\n> config itself.\n> \n> -Peff\n> \n> [1] Looking at git_diff_ui_config(), which are all the options read by\n>      porcelain git-diff but not by plumbing git-diff-files, etc, there\n>      may be other config in the same boat. E.g., I'd guess that people\n>      with diff.colormoved set would appreciate seeing that effect in the\n>      colorized versions we show. But I think it is OK to just consider\n>      diff.context for now, and see if anybody ever cares enough about\n>      other options to look into them.\n> \n\n"},{"id":"517116","messageId":"bf7f6606-e719-4c3d-b7ab-ef7351f66f37@gmail.com","threadId":"63367","inReplyTo":"CAP9jKjGb-Rcr=RLJEzeFdtrekYM+qmHy+1T1fykU3n9cV4GhGw@mail.gmail.com","subject":"Re: Discussion for interactive --patch commands to get --unified support","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-05-02T14:39:25Z","receivedAt":"2025-05-02T14:39:45Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 29/04/2025 10:16, Leon Michalak wrote:\n> \n> (https://stackoverflow.com/questions/6711670/git-show-more-context-when-using-git-add-i-or-git-add-e)\n> which mentions you can do `GIT_DIFF_OPTS=-u<number> git add -p` which\n> does work however isn't very user friendly or convenient.\nThis is a question for others on the list rather than Leon - is it \nintentional that the plumbing diff commands respect GIT_DIFF_OPTS? If a \nscript that wants to create a diff with a certain number of context \nlines runs `git diff-index -U <context>` is it helpful for that to be \noverridden if GIT_DIFF_OPTS happens to be set in the environment? \nLooking at the history it seems that environment variable used to be the \nonly way to override the default context setting but that's not the case \nnow.\n\nBest Wishes\n\nPhillip\n"},{"id":"517119","messageId":"CAP9jKjG+khoUmRpVJ8om-bs_qjB=VFCj3p3h0VSaBHVnqPLNVg@mail.gmail.com","threadId":"63367","inReplyTo":"bf7f6606-e719-4c3d-b7ab-ef7351f66f37@gmail.com","subject":"Re: Discussion for interactive --patch commands to get --unified support","fromName":"Leon Michalak","fromEmail":"leonmichalak6@gmail.com","sentAt":"2025-05-02T16:14:22Z","receivedAt":"2025-05-02T16:14:35Z","isPatch":false,"sender":{"key":"leonmichalak6@gmail.com","avatar":"https://avatars.githubusercontent.com/u/63664402?v=4"},"body":"Inheriting the diff.context setting is what scratches my itch the most, although\nalso being able to set the context in the command list of `add -i`\nsounds interesting too. Personally, I don't think I would use the\ncommand line overrides too much myself as most of the time (like with\ndiff) I'd like to set the option and forget it but it does have a\ncertain consistency to it.\n\nSlightly off-topic to the discussion, but does anyone have advice on\nhow to deal with providing a sentinel value for something like\ncontext? I'd expect to pass `--unified` to the underlying diff command\n*only* if the user specifically has overridden it via command line\noption or a diff.context config, just like diff.algorithm has done,\nhowever diff.algorithm is a `char *` so the value can be NULL which is\na good sentinel value. My thinking is then the underlying command can\njust deal with the value as it sees it, such as giving a default if\nnot provided or making sure it's a minimum of 0 etc. Otherwise the\nlevel above has to deal with it which then probably involves\n`git_diff_ui_config` and other validations which I don't even think is\nit's responsibility and would probably duplicate logic unncessarily?\n\nI may be completely off in my assumptions here being new to the\ncodebase, so if anyone has any thoughts I'd greatly appreciate any\ncomments!\n\nOn Fri, 2 May 2025 at 15:39, Phillip Wood <phillip.wood123@gmail.com> wrote:\n>\n> On 29/04/2025 10:16, Leon Michalak wrote:\n> >\n> > (https://stackoverflow.com/questions/6711670/git-show-more-context-when-using-git-add-i-or-git-add-e)\n> > which mentions you can do `GIT_DIFF_OPTS=-u<number> git add -p` which\n> > does work however isn't very user friendly or convenient.\n> This is a question for others on the list rather than Leon - is it\n> intentional that the plumbing diff commands respect GIT_DIFF_OPTS? If a\n> script that wants to create a diff with a certain number of context\n> lines runs `git diff-index -U <context>` is it helpful for that to be\n> overridden if GIT_DIFF_OPTS happens to be set in the environment?\n> Looking at the history it seems that environment variable used to be the\n> only way to override the default context setting but that's not the case\n> now.\n>\n> Best Wishes\n>\n> Phillip\n"},{"id":"517120","messageId":"CAP9jKjFEFNFK_dRCAFj224=AE=5k4RsJhspVUFhzQJia8GOdwg@mail.gmail.com","threadId":"63367","inReplyTo":"CAP9jKjG+khoUmRpVJ8om-bs_qjB=VFCj3p3h0VSaBHVnqPLNVg@mail.gmail.com","subject":"Re: Discussion for interactive --patch commands to get --unified support","fromName":"Leon Michalak","fromEmail":"leonmichalak6@gmail.com","sentAt":"2025-05-02T16:23:39Z","receivedAt":"2025-05-02T16:23:52Z","isPatch":false,"sender":{"key":"leonmichalak6@gmail.com","avatar":"https://avatars.githubusercontent.com/u/63664402?v=4"},"body":"Correction to my above message, I meant to reference\n`repo_diff_setup`, not `git_diff_ui_config` as that lets you\ninitialise a struct with the default context value that diff uses\n(assuming I have understood correctly)\n\nOn Fri, 2 May 2025 at 17:14, Leon Michalak <leonmichalak6@gmail.com> wrote:\n>\n> Inheriting the diff.context setting is what scratches my itch the most, although\n> also being able to set the context in the command list of `add -i`\n> sounds interesting too. Personally, I don't think I would use the\n> command line overrides too much myself as most of the time (like with\n> diff) I'd like to set the option and forget it but it does have a\n> certain consistency to it.\n>\n> Slightly off-topic to the discussion, but does anyone have advice on\n> how to deal with providing a sentinel value for something like\n> context? I'd expect to pass `--unified` to the underlying diff command\n> *only* if the user specifically has overridden it via command line\n> option or a diff.context config, just like diff.algorithm has done,\n> however diff.algorithm is a `char *` so the value can be NULL which is\n> a good sentinel value. My thinking is then the underlying command can\n> just deal with the value as it sees it, such as giving a default if\n> not provided or making sure it's a minimum of 0 etc. Otherwise the\n> level above has to deal with it which then probably involves\n> `git_diff_ui_config` and other validations which I don't even think is\n> it's responsibility and would probably duplicate logic unncessarily?\n>\n> I may be completely off in my assumptions here being new to the\n> codebase, so if anyone has any thoughts I'd greatly appreciate any\n> comments!\n>\n> On Fri, 2 May 2025 at 15:39, Phillip Wood <phillip.wood123@gmail.com> wrote:\n> >\n> > On 29/04/2025 10:16, Leon Michalak wrote:\n> > >\n> > > (https://stackoverflow.com/questions/6711670/git-show-more-context-when-using-git-add-i-or-git-add-e)\n> > > which mentions you can do `GIT_DIFF_OPTS=-u<number> git add -p` which\n> > > does work however isn't very user friendly or convenient.\n> > This is a question for others on the list rather than Leon - is it\n> > intentional that the plumbing diff commands respect GIT_DIFF_OPTS? If a\n> > script that wants to create a diff with a certain number of context\n> > lines runs `git diff-index -U <context>` is it helpful for that to be\n> > overridden if GIT_DIFF_OPTS happens to be set in the environment?\n> > Looking at the history it seems that environment variable used to be the\n> > only way to override the default context setting but that's not the case\n> > now.\n> >\n> > Best Wishes\n> >\n> > Phillip\n"},{"id":"517125","messageId":"xmqqfrhnuf06.fsf@gitster.g","threadId":"63367","inReplyTo":"CAP9jKjG+khoUmRpVJ8om-bs_qjB=VFCj3p3h0VSaBHVnqPLNVg@mail.gmail.com","subject":"Re: Discussion for interactive --patch commands to get --unified support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-02T16:57:45Z","receivedAt":"2025-05-02T16:57:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Leon Michalak <leonmichalak6@gmail.com> writes:\n\n> Inheriting the diff.context setting is what scratches my itch the most, although\n> also being able to set the context in the command list of `add -i`\n> sounds interesting too. Personally, I don't think I would use the\n> command line overrides too much myself as most of the time (like with\n> diff) I'd like to set the option and forget it but it does have a\n> certain consistency to it.\n\nSounds good.\n\n> Slightly off-topic to the discussion, but does anyone have advice on\n> how to deal with providing a sentinel value for something like\n> context?\n\nSeeing in diff.c\n\n    static int diff_context_default = 3;\n    static int diff_interhunk_context_default;\n\nthat they are of signed type, and negative context would not make\nsense (would it???), wouldn't -1 be a good \"they haven't touched\nthis from the command line or configuration\" value?\n"},{"id":"517126","messageId":"CAP9jKjEbb_ABmGmLNwn=ruh+BOR73QDqtzF-cCYv40cE47fEGQ@mail.gmail.com","threadId":"63367","inReplyTo":"xmqqfrhnuf06.fsf@gitster.g","subject":"Re: Discussion for interactive --patch commands to get --unified support","fromName":"Leon Michalak","fromEmail":"leonmichalak6@gmail.com","sentAt":"2025-05-02T17:13:15Z","receivedAt":"2025-05-02T17:13:28Z","isPatch":false,"sender":{"key":"leonmichalak6@gmail.com","avatar":"https://avatars.githubusercontent.com/u/63664402?v=4"},"body":"This is what I have been using currently although the perfectionist in\nme says that a user could pass `--unified=-1` and the code would treat\nthat as if nothing was passed by the user.\n\nIn practice, I guess this doesn't really matter. I think that was\nprobably a needed sanity check, thanks\n\nOn Fri, 2 May 2025, 17:57 Junio C Hamano, <gitster@pobox.com> wrote:\n>\n> Leon Michalak <leonmichalak6@gmail.com> writes:\n>\n> > Inheriting the diff.context setting is what scratches my itch the most, although\n> > also being able to set the context in the command list of `add -i`\n> > sounds interesting too. Personally, I don't think I would use the\n> > command line overrides too much myself as most of the time (like with\n> > diff) I'd like to set the option and forget it but it does have a\n> > certain consistency to it.\n>\n> Sounds good.\n>\n> > Slightly off-topic to the discussion, but does anyone have advice on\n> > how to deal with providing a sentinel value for something like\n> > context?\n>\n> Seeing in diff.c\n>\n>     static int diff_context_default = 3;\n>     static int diff_interhunk_context_default;\n>\n> that they are of signed type, and negative context would not make\n> sense (would it???), wouldn't -1 be a good \"they haven't touched\n> this from the command line or configuration\" value?\n"},{"id":"517127","messageId":"xmqqbjsavp0a.fsf@gitster.g","threadId":"63367","inReplyTo":"CAP9jKjEbb_ABmGmLNwn=ruh+BOR73QDqtzF-cCYv40cE47fEGQ@mail.gmail.com","subject":"Re: Discussion for interactive --patch commands to get --unified support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-02T18:36:21Z","receivedAt":"2025-05-02T18:36:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Leon Michalak <leonmichalak6@gmail.com> writes:\n\n> This is what I have been using currently although the perfectionist in\n> me says that a user could pass `--unified=-1` and the code would treat\n> that as if nothing was passed by the user.\n\nThe command line parser and corresponding config parser callback can\nbe careful to check the value they get from the end user to avoid\nthat, can't they?\n\nIn any case, it is PEBKAC when the end-users do that, and they\ncannot complain about their --unified=-1 are ignored.  We do not\nhave to care, and can just tell them \"Don't do that, then.\"\n"}]}