Re: [PATCH v3] git-jump: pick a mode automatically when invoked without arguments

From: Erik Cervin Edin <erik@cervined.in>
Date: May 26, 2026, 21:33 UTC
Message-ID: <ahYN_FeSileUJLGl@mbp>
In-Reply-To: <20260522052821.GC861761@coredump.intra.peff.net>

On 26/05/22 01:28AM, Jeff King wrote:

Show 9 quoted lines

> 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:

Show 5 quoted lines

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