From: "Julia Evans" <julia@jvns.ca>
To: "Junio C Hamano" <gitster@pobox.com>,
"Julia Evans" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, "D. Ben Knoble" <ben.knoble@gmail.com>
Subject: Re: [PATCH v2] doc: git-diff: rewrite EXAMPLES section
Date: Tue, 10 Nov 2026 08:43:46 -0500 [thread overview]
Message-ID: <85cbf068-08e2-40cc-9460-d537bc61e122@app.fastmail.com> (raw)
In-Reply-To: <xmqqse1fuoof.fsf@gitster.g>
>>> + git diff [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]
>>> ++git diff [<options>] --staged [--merge-base] [<commit>] [--] [<path>...]
>>
>> or something).
>
> Clarification.
>
> The point is that there is a difference between giving wider
> exposure to "--staged" as an accepted synonym and swapping offical
> option with the synonym, let alone deprecating "--cached".
Sorry, that's embarrassing, I didn't mean to include this change.
I did an experimental rewrite to see what it would like to rename `--cached`
to `--staged`, decided it would be better to keep the scope small,
and I thought I'd undone it before submitting it.
Will take this out.
>>> +@@ Documentation/git-diff.adoc: files on disk.
>>> + do not give _<commit>_, it defaults to `HEAD`.
>>> + If `HEAD` does not exist (e.g. unborn branches) and
>>> + _<commit>_ is not given, it shows all staged changes.
>>> +- `--staged` is a synonym of `--cached`.
>>> ++ `--cached` is a synonym of `--staged`.
>>
>> And this is the other way around.
>>
>> Other than that, the rest, including the resurrection of AUTO_MERGE,
>> looked OK.
Good to hear.
next prev parent reply other threads:[~2026-11-10 13:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 15:33 [PATCH] doc: git-diff: rewrite EXAMPLES section Julia Evans via GitGitGadget
2026-11-03 17:16 ` Julia Evans
2026-11-03 19:44 ` Junio C Hamano
2026-11-03 19:52 ` Julia Evans
2026-11-03 20:33 ` Junio C Hamano
2026-11-03 20:45 ` Julia Evans
2026-11-03 21:42 ` Junio C Hamano
2026-11-05 15:40 ` [PATCH v2] " Julia Evans via GitGitGadget
2026-11-05 16:46 ` Junio C Hamano
2026-11-05 18:18 ` Junio C Hamano
2026-11-09 12:48 ` D. Ben Knoble
2026-11-10 13:43 ` Julia Evans [this message]
2026-11-05 17:23 ` Tuomas Ahola
2026-11-05 19:45 ` Junio C Hamano
2026-11-05 19:46 ` Junio C Hamano
2026-11-08 2:37 ` Jeff King
2026-11-08 4:35 ` Junio C Hamano
2026-11-09 18:53 ` Jeff King
2026-11-09 20:31 ` Junio C Hamano
2026-11-09 22:20 ` Junio C Hamano
2026-11-09 22:40 ` Junio C Hamano
2026-11-09 23:09 ` Jeff King
2026-11-10 13:46 ` Julia Evans
2026-11-10 15:25 ` Kaartic Sivaraam
2026-11-11 20:17 ` Julia Evans
2026-11-10 17:22 ` Junio C Hamano
2026-11-11 20:13 ` [PATCH v3] " Julia Evans via GitGitGadget
2026-11-11 21:52 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85cbf068-08e2-40cc-9460-d537bc61e122@app.fastmail.com \
--to=julia@jvns.ca \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox