Thanks to visit codestin.com
Credit goes to Github.com

Skip to content

Conversation

@HaraldNordgren
Copy link
Contributor

@HaraldNordgren HaraldNordgren commented Dec 18, 2025

cc: Collin Funk [email protected]
cc: Phillip Wood [email protected]
cc: Ben Knoble [email protected]
cc: Chris Torek [email protected]
cc: Johannes Sixt [email protected]

@gitgitgadget-git
Copy link

Welcome to GitGitGadget

Hi @HaraldNordgren, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.

Please make sure that either:

  • Your Pull Request has a good description, if it consists of multiple commits, as it will be used as cover letter.
  • Your Pull Request description is empty, if it consists of a single commit, as the commit message should be descriptive enough by itself.

You can CC potential reviewers by adding a footer to the PR description with the following syntax:

CC: Revi Ewer <[email protected]>, Ill Takalook <[email protected]>

NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description,
because it will result in a malformed CC list on the mailing list. See
example.

Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:

  • the lines should not exceed 76 columns,
  • the first line should be like a header and typically start with a prefix like "tests:" or "revisions:" to state which subsystem the change is about, and
  • the commit messages' body should be describing the "why?" of the change.
  • Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.

It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.

Contributing the patches

Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form /allow. A good way to find other contributors is to locate recent pull requests where someone has been /allowed:

Both the person who commented /allow and the PR author are able to /allow you.

An alternative is the channel #git-devel on the Libera Chat IRC network:

<newcontributor> I've just created my first PR, could someone please /allow me? https://github.com/gitgitgadget/git/pull/12345
<veteran> newcontributor: it is done
<newcontributor> thanks!

Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.

If you want to see what email(s) would be sent for a /submit request, add a PR comment /preview to have the email(s) sent to you. You must have a public GitHub email address for this. Note that any reviewers CC'd via the list in the PR description will not actually be sent emails.

After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail).

If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the (raw) link), then import it into your mail program. If you use GMail, you can do this via:

curl -g --user "<EMailAddress>:<Password>" \
    --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

To iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description):

Changes since v1:
- Fixed a typo in the commit message (found by ...)
- Added a code comment to ... as suggested by ...
...

To send a new iteration, just add another PR comment with the contents: /submit.

Need help?

New contributors who want advice are encouraged to join [email protected], where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join.

You may also be able to find help in real time in the developer IRC channel, #git-devel on Libera Chat. Remember that IRC does not support offline messaging, so if you send someone a private message and log out, they cannot respond to you. The scrollback of #git-devel is archived, though.

@gitgitgadget-git
Copy link

There are issues in commit 0c7c1e2:
diff: create 'no-indicators' flag to not show '+' and '-' indicators in the left margin
Commit checks stopped - the message is too short
First line of commit message is too long (> 76 columns)
Commit not signed off

@gitgitgadget-git
Copy link

There are issues in commit d3d4887:
diff: create 'no-indicators' flag to not show '+' and '-' indicators in the left margin
Commit checks stopped - the message is too short
First line of commit message is too long (> 76 columns)
Commit not signed off

@gitgitgadget-git
Copy link

There are issues in commit 0038b81:
diff: create 'no-indicators' flag to not show '+' and '-' indicators in the left margin
Commit checks stopped - the message is too short
First line of commit message is too long (> 76 columns)
Commit not signed off

@gitgitgadget-git
Copy link

There are issues in commit e7971d2:
diff: create 'no-indicators' flag to not show '+' and '-' indicators in the left margin
First line of commit message is too long (> 76 columns)
Commit not signed off
Lines in the body of the commit messages should be wrapped between 60 and 76 characters.
Indented lines, and lines without whitespace, are exempt

@gitgitgadget-git
Copy link

There are issues in commit db667fa:
diff: create 'no-indicators' flag to not show '+' and '-' indicators in the
Commit not signed off
The first line must be separated from the rest by an empty line

@HaraldNordgren HaraldNordgren force-pushed the no-indicators branch 2 times, most recently from e31ce19 to dbc415b Compare December 18, 2025 20:01
@gitgitgadget-git
Copy link

There are issues in commit dbc415b:
diff: create 'no-indicators' flag to not show '+' and '-' indicators in the
The first line must be separated from the rest by an empty line

@gitgitgadget-git
Copy link

There are issues in commit fedd993:
diff: create 'no-indicators' flag to not show '+' and '-' indicators in the
The first line must be separated from the rest by an empty line

@HaraldNordgren
Copy link
Contributor Author

/preview

@gitgitgadget-git
Copy link

Error: User HaraldNordgren is not yet permitted to use GitGitGadget

@HaraldNordgren
Copy link
Contributor Author

HaraldNordgren commented Dec 18, 2025

Hi @dscho, @slburson or @rajathkannabiran, can someone help me with an /allow 🤗

@HaraldNordgren HaraldNordgren force-pushed the no-indicators branch 2 times, most recently from b0f0f19 to 78163cf Compare December 18, 2025 23:35
@HaraldNordgren HaraldNordgren changed the title diff: create 'no-indicators' flag to not show '+' and '-' indicators in the left margin diff: add --no-indicators option Dec 18, 2025
@HaraldNordgren HaraldNordgren changed the title diff: add --no-indicators option diff: add '--no-indicators' option Dec 18, 2025
@dscho
Copy link
Member

dscho commented Dec 19, 2025

/allow

@gitgitgadget-git
Copy link

User HaraldNordgren is now allowed to use GitGitGadget.

@HaraldNordgren
Copy link
Contributor Author

/preview

@gitgitgadget-git
Copy link

Preview email sent as [email protected]

@HaraldNordgren
Copy link
Contributor Author

/submit

@gitgitgadget-git
Copy link

Submitted as [email protected]

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-git-2133/HaraldNordgren/no-indicators-v1

To fetch this version to local tag pr-git-2133/HaraldNordgren/no-indicators-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-git-2133/HaraldNordgren/no-indicators-v1

@gitgitgadget-git
Copy link

On the Git mailing list, Collin Funk wrote (reply to this):

"Harald Nordgren via GitGitGadget" <[email protected]> writes:

> From: Harald Nordgren <[email protected]>
>
> 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 <[email protected]>
> ---
>     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(+)

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

@gitgitgadget-git
Copy link

User Collin Funk <[email protected]> has been added to the cc: list.

@gitgitgadget-git
Copy link

On the Git mailing list, Phillip Wood wrote (reply to this):

Hi Harald

On 19/12/2025 08:17, Harald Nordgren via GitGitGadget wrote:
> From: Harald Nordgren <[email protected]>
> > 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.

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

> Signed-off-by: Harald Nordgren <[email protected]>
> ---
>      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(+)
> > diff --git a/diff.c b/diff.c
> index 436da250eb..668ba349fe 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -5290,6 +5290,20 @@ static int diff_opt_char(const struct option *opt,
>   	return 0;
>   }
>   > +static int diff_opt_no_indicators(const struct option *opt,
> +				  const char *arg, int unset)
> +{
> +	struct diff_options *options = opt->value;
> +
> +	BUG_ON_OPT_NEG(unset);
> +	BUG_ON_OPT_ARG(arg);
> +
> +	options->output_indicators[OUTPUT_INDICATOR_NEW] = ' ';
> +	options->output_indicators[OUTPUT_INDICATOR_OLD] = ' ';
> +	options->output_indicators[OUTPUT_INDICATOR_CONTEXT] = ' ';
> +	return 0;
> +}
> +
>   static int diff_opt_color_moved(const struct option *opt,
>   				const char *arg, int unset)
>   {
> @@ -5828,6 +5842,9 @@ struct option *add_diff_options(const struct option *opts,
>   		OPT_INTEGER_F(0, "inter-hunk-context", &options->interhunkcontext,
>   			      N_("show context between diff hunks up to the specified number of lines"),
>   			      PARSE_OPT_NONEG),
> +		OPT_CALLBACK_F(0, "no-indicators", options, NULL,
> +			       N_("do not show '+', '-' and ' ' indicators in the left margin"),
> +			       PARSE_OPT_NONEG | PARSE_OPT_NOARG, diff_opt_no_indicators),
>   		OPT_CALLBACK_F(0, "output-indicator-new",
>   			       &options->output_indicators[OUTPUT_INDICATOR_NEW],
>   			       N_("<char>"),
> diff --git a/t/t4000-diff-format.sh b/t/t4000-diff-format.sh
> index 32b14e3a71..1863553056 100755
> --- a/t/t4000-diff-format.sh
> +++ b/t/t4000-diff-format.sh
> @@ -95,6 +95,38 @@ test_expect_success 'git diff-files --patch --no-patch does not show the patch'
>   	test_must_be_empty err
>   '
>   > +cat >expected_no_indicators <<\EOF
> +diff --git a/path0 b/path0
> +old mode 100644
> +new mode 100755
> +--- a/path0
> ++++ b/path0
> +@@ -1,3 +1,3 @@
> + Line 1
> + Line 2
> + line 3
> + Line 3
> +diff --git a/path1 b/path1
> +deleted file mode 100755
> +--- a/path1
> ++++ /dev/null
> +@@ -1,3 +0,0 @@
> + Line 1
> + Line 2
> + line 3
> +EOF
> +
> +test_expect_success 'git diff-files --no-indicators replaces +/- with spaces' '
> +	git diff-files -p --no-indicators >actual &&
> +	compare_diff_patch expected_no_indicators actual
> +'
> +
> +test_expect_success 'git diff-files --no-indicators --color preserves colors' '
> +	git diff-files -p --no-indicators --color --ws-error-highlight=none >actual.raw &&
> +	test_decode_color <actual.raw >actual &&
> +	grep -F "<RED> line 3<RESET>" actual &&
> +	grep -F "<GREEN> Line 3<RESET>" actual
> +'
>   >   # Smudge path2/path3 so that dirstat has something to show
>   date >path2/path3
> > base-commit: c4a0c8845e2426375ad257b6c221a3a7d92ecfda

@gitgitgadget-git
Copy link

User Phillip Wood <[email protected]> has been added to the cc: list.

@gitgitgadget-git
Copy link

On the Git mailing list, Harald Nordgren wrote (reply to this):

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

@gitgitgadget-git
Copy link

On the Git mailing list, Harald Nordgren wrote (reply to this):

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

@gitgitgadget-git
Copy link

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Harald Nordgren via GitGitGadget" <[email protected]> writes:

> From: Harald Nordgren <[email protected]>
>
> 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.

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.

@gitgitgadget-git
Copy link

On the Git mailing list, Ben Knoble wrote (reply to this):

> Le 19 déc. 2025 à 07:27, Harald Nordgren <[email protected]> a écrit :
> 
> 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. 

@gitgitgadget-git
Copy link

User Ben Knoble <[email protected]> has been added to the cc: list.

@gitgitgadget-git
Copy link

On the Git mailing list, Phillip Wood wrote (reply to this):

On 19/12/2025 11:46, Harald Nordgren wrote:
> 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.

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=[email protected]

> Harald
> 

@gitgitgadget-git
Copy link

On the Git mailing list, Chris Torek wrote (reply to this):

On Fri, Dec 19, 2025 at 6:27 AM Phillip Wood <[email protected]> wrote:
> 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. ...

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

@gitgitgadget-git
Copy link

User Chris Torek <[email protected]> has been added to the cc: list.

@gitgitgadget-git
Copy link

On the Git mailing list, Harald Nordgren wrote (reply to this):

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:

```
--- a/src/ui/components/SatietyIndicator.tsx
+++ b/src/ui/components/SatietyIndicator.tsx

   const spcGoalCompletionOuterGAnimProps = useAnimatedProps(() => {
     return {
-      opacity: satietyGoalScore
+      opacity: shouldShowGoalMarker
         ? interpolate(spcGoalMarkerOpacitySV.value, [0, 1], [1, 0])
         : 0,
     }
@@ -364,7 +372,7 @@ export const SatietyIndicator: FC<Props> = ({

     const centerAdjustment = -(CHECKMARK_SIZE * scale) / 2

-    return satietyGoalScore
+    return shouldShowGoalMarker
       ? {
           transform: [
             {scale: scale},
@@ -383,11 +391,19 @@ export const SatietyIndicator: FC<Props> = ({
         {shouldShowReachHere && (
           <AnimatedBox
             position={'absolute'}
-            top={spcGoalMarkerPositionStaticProps.y - 18}
-            left={spcGoalMarkerPositionStaticProps.x - 9}
+            top={
+              spcGoalMarkerPositionStaticProps.y -
+              ARROW_SIZE / 2 +
+              ARROW_OUTWARD_OFFSET * Math.sin(arrowAngleRadians)
+            }
+            left={
+              spcGoalMarkerPositionStaticProps.x -
+              ARROW_SIZE / 2 +
+              ARROW_OUTWARD_OFFSET * Math.cos(arrowAngleRadians)
+            }
             style={arrowBounceStyle}>
             <PointerArrow
-              size={18}
+              size={ARROW_SIZE}
               color={'black'}
               angle={270 + arrowTiltDegrees}
             />
```

I do this already, it just has the extra step of having to go through
manually and remove +/- characters. Since already have the red and green
colors to judge me, +/- doesn't help anything.

I would also like to add this to 'git show'

Harald

@gitgitgadget-git
Copy link

On the Git mailing list, Harald Nordgren wrote (reply to this):

Hi Chris!

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

@gitgitgadget-git
Copy link

On the Git mailing list, Chris Torek wrote (reply to this):

On Fri, Dec 19, 2025 at 6:54 AM Harald Nordgren
<[email protected]> wrote:
> Hi Chris!
>
> Thanks for the idea, but that doesn't seem fast at all 😅

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

@gitgitgadget-git
Copy link

On the Git mailing list, Harald Nordgren wrote (reply to this):

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

@gitgitgadget-git
Copy link

On the Git mailing list, Harald Nordgren wrote (reply to this):

Hi Ben!

Here is the use can when it would be useful: https://lore.kernel.org/git/[email protected]/

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

Harald

@gitgitgadget-git
Copy link

On the Git mailing list, Harald Nordgren wrote (reply to this):

Hi Mr. Hamano!

Here is my classic use-case: https://lore.kernel.org/git/[email protected]/

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

@gitgitgadget-git
Copy link

On the Git mailing list, Junio C Hamano wrote (reply to this):

Harald Nordgren <[email protected]> writes:

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

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".

@gitgitgadget-git
Copy link

On the Git mailing list, Harald Nordgren wrote (reply to this):

> 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

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 <[email protected]>
@gitgitgadget-git
Copy link

On the Git mailing list, Johannes Sixt wrote (reply to this):

Am 19.12.25 um 15:50 schrieb Harald Nordgren:
> 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:
> 
> ```
> --- a/src/ui/components/SatietyIndicator.tsx
> +++ b/src/ui/components/SatietyIndicator.tsx
> 
>    const spcGoalCompletionOuterGAnimProps = useAnimatedProps(() => {
>      return {
> -      opacity: satietyGoalScore
> +      opacity: shouldShowGoalMarker
>          ? interpolate(spcGoalMarkerOpacitySV.value, [0, 1], [1, 0])
>          : 0,
>      }
> @@ -364,7 +372,7 @@ export const SatietyIndicator: FC<Props> = ({
> 
>      const centerAdjustment = -(CHECKMARK_SIZE * scale) / 2
> 
> -    return satietyGoalScore
> +    return shouldShowGoalMarker
>        ? {
>            transform: [
>              {scale: scale},
> @@ -383,11 +391,19 @@ export const SatietyIndicator: FC<Props> = ({
>          {shouldShowReachHere && (
>            <AnimatedBox
>              position={'absolute'}
> -            top={spcGoalMarkerPositionStaticProps.y - 18}
> -            left={spcGoalMarkerPositionStaticProps.x - 9}
> +            top={
> +              spcGoalMarkerPositionStaticProps.y -
> +              ARROW_SIZE / 2 +
> +              ARROW_OUTWARD_OFFSET * Math.sin(arrowAngleRadians)
> +            }
> +            left={
> +              spcGoalMarkerPositionStaticProps.x -
> +              ARROW_SIZE / 2 +
> +              ARROW_OUTWARD_OFFSET * Math.cos(arrowAngleRadians)
> +            }
>              style={arrowBounceStyle}>
>              <PointerArrow
> -              size={18}
> +              size={ARROW_SIZE}
>                color={'black'}
>                angle={270 + arrowTiltDegrees}
>              />
> ```
> 
> I do this already, it just has the extra step of having to go through
> manually and remove +/- characters. Since already have the red and green
> colors to judge me, +/- doesn't help anything.
> 
> I would also like to add this to 'git show'
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

@gitgitgadget-git
Copy link

User Johannes Sixt <[email protected]> has been added to the cc: list.

@vanne02577-lang
Copy link

Preview email sent as [email protected]

@vanne02577-lang
Copy link

Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants