patchdiff: add --no-indicators option

From: Harald Nordgren <haraldnordgren@gmail.com>

Add --no-indicators to replace '+', '-', and ' ' indicators in the left margin with spaces. Colors are preserved, allowing diffs to be distinguished by color alone.

This is useful when copy-pasting diff output, as the indicators no longer need to be manually removed.

Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
    diff: add '--no-indicators' option

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2133%2FHaraldNordgren%2Fno-indicators-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2133/HaraldNordgren/no-indicators-v1
Pull-Request: https://github.com/git/git/pull/2133

 diff.c                 | 17 +++++++++++++++++
 t/t4000-diff-format.sh | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 49 insertions(+)

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

Would a 'sed' command work for this? Something like:

    $ git diff --color=always HEAD~ \
        | sed -E '/^(\x1b\[[0-9;]*m)*(-{3} a|\+{3} b)/b
                  s/^((\x1b\[[0-9;]*m)*)[-+]/\1 /'

My impression is that indicators are wanted for diff's most (all?) of the time.

Collin

Hi Collin!

Surely, "git diff --output-indicator-old=' ' --output-indicator-new=' '" exists for a reason, to allow users to customize the workflow for themselves. So this is adding a better short-hand instead of that, which feels a bit clunky. Sed workaround would likely work, but nicer to have it native inside git instead?

I use Git from the CLI 99.99% of the time, and find myself often copy- pasting to recover some code from and old commit, so then this helps to save me pasting in and the manually removing the +/- signs. Not a huge deal, but makes the awesome Git CLI even better.

Harald

I wondered why you’d be copying diffs without leading indicators; with that answered, perhaps you should try “git restore”? One benefit of version control is easily restoring other versions. 

Hi Ben!

Here is the use can when it would be useful: https://lore.kernel.org/git/20251219145037.17880-1-haraldnordgren@gmail.com/

You don't need to tell me about the benefits of version control 😬

Harald

Hi Harald

On 19/12/2025 08:17, Harald Nordgren via GitGitGadget wrote:

But you're still left with a space at the beginning of each line. I'd have thought it would be better for --no-indicators to just strip the leading '+', ' ', '-' though that still leaves us with

     \ No newline at end of file

should that whole line be stripped as well?

If you just want to replace the indicators with a space then you can always set up an alias that does

     diff --output-indicator-old=' '  --output-indicator-new=' ' \
          --output-indicator-context=' '

The --output-indicator-* options error out if you pass an empty string so you cannot use them to remove the indicators all together.

Thanks

Phillip

Hi Phillip!

Yeah, getting rid of the extra space in the beginning would be preferable, I can take a look at that assuming that this has any chance of getting merged.

Harald

On 19/12/2025 11:46, Harald Nordgren wrote:

I can't say whether any given patch will be merged or not. All I can say is that if there is support for an idea on the mailing list and someone submits a sensible implementation then it is likely to be merged. If people on the mailing list are generally unconvinced something is a good idea then it is unlikely to be merged.

If you want to restore some lines from a previous version of the file then it would be worth trying out "git restore -p" as Ben suggested. If there is some other use for this then it would be helpful to understand a bit more about it. I'm struggling to see why it would be useful to be able to copy and paste a mixture of insertions and deletions without the '+' and '-' indicators. There was some discussion a while ago about being able to view just the new version of the file[1] would it make sense to just show the old or new version when the indicators are omitted?

Thanks

Phillip

[1] https://lore.kernel.org/git/CAHk-=wgh8emJn-+FtxN=m_SCPiP6cGKHU-5ozzV9tWBMxn+xcA@mail.gmail.com

On Fri, Dec 19, 2025 at 6:27 AM Phillip Wood <phillip.wood123@gmail.com> wrote:

As someone who makes a lot of tpyos and hsa text that gets duplicaged because of copypasta duplicaged because of copypasta errors and on on (ahem), my personal preference tends towards:

    $ git show <rev1>:<path>  > file.oldver
    $ git show <rev2>:<path>  > file.newver
    $ vim file file.oldver file.newver

and then cut/paste old or new parts in the editor, rather than with a mouse that doesn't always get the proper edge points. The ability to "git show" specific versions of files is the key here.

(The patch modes of git add/restore are good for small things.)

Chris

Hi Chris!

Thanks for the idea, but that doesn't seem fast at all 😅

On Fri, Dec 19, 2025 at 6:54 AM Harald Nordgren <haraldnordgren@gmail.com> wrote:

It's terrifically easy to script. Instead of:

    git show $rev -- $path

you need:

    git show ${rev}^:$path >$path.old
    git show ${rev}:$path >$path.new

which in sh/bash is (you can fancy this up some):

    rev=$(git rev-parse "$1") || exit
    path=$2

followed by the two "git show" commands. Using ${rev}^ gets you the raw hash ID of the specified revision followed by the caret / hat suffix, which means "parent of the given rev", so all you need to specify to the mini-script is the same rev you'd pass to "git show" and the path name.

(I don't need this often enough to bother with the script, I just type in the commands.)

Chris

Hi Chris!

Thanks! I get that we can wrap things in scripts, but I find that it doesn't help when working with a team. Other people don't like homemade bash scripts.

It's much easier to convince someone to use a feaute when it's built- into git itself. Just my experience.

Harald

Hi Collin!

The use case for me is when working on a feature and digging through my own commits to recover a code block that I previously threw away. Then I dont't want to do 'git restore -p' and go through all the changes in that file.

I just want to quickly pick out the thing I need, that could be e.g. this snippet

```
            top={
              spcGoalMarkerPositionStaticProps.y -
              ARROW_SIZE / 2 +
              ARROW_OUTWARD_OFFSET * Math.sin(arrowAngleRadians)
            }
            left={
              spcGoalMarkerPositionStaticProps.x -
              ARROW_SIZE / 2 +
              ARROW_OUTWARD_OFFSET * Math.cos(arrowAngleRadians)
            }
```

from the full diff below:

```

Am 19.12.25 um 15:50 schrieb Harald Nordgren:

I think you are looking for `git difftool`. For me, on Linux it uses meld, on Windows, I've configured it to use WinMerge. With both it is very easy to move hunks or even just individual lines between versions.

-- Hannes

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

If you are cutting more than two lines, then the first column, whether it is '+' or neutered ' ', needs to be removed. And even if you are cutting just one line, you'd still need to deal with the byte in the first column, whether it is '+' or ' ', by either cutting from the second column or removing the first column after pasting.

Also, if your terminal emulator allows cutting from Nth column to the right (e.g., "screen" allows this), it does not matter what the first letter is. You can just say "cut from the 2nd column" and you are done.

So, I am not sure if this is something we want to support. Are there other people's "diff" implementations (like GNU or BSD) that has something like that? If not, it takes a lot more to convince others.

Hi Mr. Hamano!

Here is my classic use-case: https://lore.kernel.org/git/20251219145037.17880-1-haraldnordgren@gmail.com/

I have auto-formatting set up for all the projects I work on in my daily work (Golang and TypeScript) so leading spaces do get removed automatically. But I agree with your general point, I can take a look at removing the leading column for this patch, it makes the code nicer of course! As you know, the current implementations of 'output-indicator-*' don't support empty string, so a little bit of extra work is needed for that.

Regarding "cutting from Nth column", I use macOS with iTerm 2 and I'm not sure if that functionality exists there. It's of course possible for me to keep copy-pasting the whole blob and removing the +/- signs manually or via some scripts, but seems like a lost oppornunity to not handle this from git?

Maybe I missed your point about GNU or BSD, could you explain more about that?

Harald

Harald Nordgren <haraldnordgren@gmail.com> writes:

When I talk/think about what "git diff" should and should not do, I remind myself that not many things under the sun are truly novel. After all, long before Git was invented, people had used "diff" to compare old and new versions of the same thing to extract the differences. When proposing a new feature X in "git diff", it would support the idea very well if these implementations of "diff" that way predates Git itself has a simliar feature already. On the other hand, if the vanilla "diff" used outside the context of Git lack such feature X, it is more likely that X is an ill-thought-out misfeature that they didn't want, than people who have been working on these implementations of "diff" (not "git diff", but GNU or BSD or others) were dumb enough that they did not think of the feature X themselves.

That was why I asked if there are precedents, either in GNU or BSD implementations of "diff".

Hi Junio!

Got it! I did some research and it seems GNU diff has features for this and BSD diff is more barebones.

GNU diff has the option to turn off +/- indicators with `--line-format='%L'`, however it also turns of colors even if supplying `--color=always`. Git doesn't have this option yet, so maybe it's time to implement it, but be a bit smarter so colors are shown its a TTY?

Harald