From: Erik Cervin Edin <erik@cervined.in>
To: git@vger.kernel.org
Subject: Re: [PATCH v3] git-jump: pick a mode automatically when invoked without arguments
Date: Tue, 26 May 2026 23:33:21 +0200 [thread overview]
Message-ID: <ahYN_FeSileUJLGl@mbp> (raw)
In-Reply-To: <20260522052821.GC861761@coredump.intra.peff.net>
On 26/05/22 01:28AM, Jeff King wrote:
> On Thu, May 21, 2026 at 01:45:09PM +0000, Greg Hurrell via GitGitGadget wrote:
>
> > * Don't both teaching "auto" to select "ws" mode, because it is always
> > subsumed by "diff".
>
> Dropping the "ws" mode from auto makes sense to me. It could be slotted
> in between "merge" and "diff" (a whitespace problem always implies a
> diff, but a diff does not always imply a whitespace problem). But would
> that actually be useful?
When I originally proposed the idea of a third branch, there was a
subtle difference -- it was a git diff --cached --check.
On 26/05/14 05:40PM, Erik Cervin Edin wrote:
> If we're going to teach git-jump how to be more clever about where to jump,
> does it also make sense to bake `git jump ws` into this?
>
> elif ! git diff --cached --check >/dev/null 2>&1; then
> mode_ws --cached "$@"
Ever so often I come across file with a diff --check offending
white-space (often a missing newline at the end of some file) and
because I have a commit hook set up, I have to go looking for where that
error is. In this particular case it's always a staged change, and then
a *staged* white space problem doesn't imply a diff.
This happens rarely enough that I haven't internalized that I can use
"git jump diff --check --cached" and it takes me a while to navigate to
the offending files.
But the main suggestion was really considering the possibility to
expand this beyond these two auto jumps in the future -- I'm not sure
an auto jump that goes looking for staged white spaces issues would be
useful to anyone in practise and at this stage I thinks it's best to
drop it.
prev parent reply other threads:[~2026-05-26 21:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 9:07 [PATCH] git-jump: pick a mode automatically when invoked without arguments Greg Hurrell via GitGitGadget
2026-05-08 14:13 ` Jeff King
2026-05-08 14:30 ` Greg Hurrell
2026-05-08 17:52 ` Jeff King
2026-05-14 15:40 ` Erik Cervin Edin
2026-05-19 9:03 ` Greg Hurrell
2026-05-19 21:22 ` Jeff King
2026-05-20 12:31 ` [PATCH v2] " Greg Hurrell via GitGitGadget
2026-05-21 1:22 ` Junio C Hamano
2026-05-21 1:30 ` Junio C Hamano
2026-05-21 13:45 ` [PATCH v3] " Greg Hurrell via GitGitGadget
2026-05-21 14:00 ` Junio C Hamano
2026-05-22 5:28 ` Jeff King
2026-05-22 7:33 ` Greg Hurrell
2026-05-26 21:33 ` Erik Cervin Edin [this message]
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=ahYN_FeSileUJLGl@mbp \
--to=erik@cervined.in \
--cc=git@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.