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

From: Jeff King <peff@peff.net>
Date: May 22, 2026, 05:28 UTC
Message-ID: <20260522052821.GC861761@coredump.intra.peff.net>
In-Reply-To: <pull.2108.v3.git.1779371110195.gitgitgadget@gmail.com>

On Thu, May 21, 2026 at 01:45:09PM +0000, Greg Hurrell via GitGitGadget wrote:

Show 15 quoted lines

>     Changes since v2; all of these in response to feedback from Junio:
>     
>      * Removed stray # from README.
>      * Don't both teaching "auto" to select "ws" mode, because it is always
>        subsumed by "diff".
>      * Update usage string to make clear that git jump --stdout foo is not a
>        synonym for git jump --stdout auto foo, because distinguishing
>        between foo as <mode> and foo as <arg> is fraught with ambiguity.
>     
>     In answer to Junio's question:
>     
>     > If more than one interesting cases apply, what happens, and what
>     > should happen?
>     
>     it's an ordered choice (merge > 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?

My impression of the "auto" feature is: I am too lazy to type, so just take me to the interesting bits. And interesting in my experience with git-jump is either "I am merging, take me to the conflict" or "I am writing new code, take me to what I already did". Limiting the second case just to whitespace violations (assuming there is at least one) would probably be more confusing than helpful.

You could perhaps argue for one more layer of "interesting", which is: if there are no unstaged changes, take me to the staged ones. Looking at staged changes can be misleading if the working tree file has moved on (since by definition we are dumping the editor into the working tree file, not the staged contents). But if we know the diff between index and working tree is empty, then that is not an issue.

I do sometimes use "git jump diff --cached" explicitly for that purpose.

If sounds like Greg has been living with "auto" and finding it useful for a while. So I'm mostly inclined to take the patch as-is, and people can experiment with it and suggest changes after using it in practice.

But here's my one final thought. The hierarchy of "merge > diff > diff --cached", etc, makes me wonder if we could simply concatenate the outputs. I.e., show all of the merge conflicts and all of the diffs, whitespace changes, and so on. But I guess you run into two issues:

  1. There will be duplicates. Every merge conflict is also a diff. And
     every whitespace violation is also a diff. So at the very least you
     need to de-dup these (which might not be entirely trivial, as they
     may overlap rather than starting at the same line).

  2. When resolving a merge, I'm not sure if the diffs are actually
     interesting. Usually I git-jump around until there are no more
     conflicts, and then I see if it builds. But I almost never want to
     jump to the other changes introduced by the side-branch. There are
     too many of them, and they are probably uninteresting. So adding
     both "merge" and "diff" elements to the quicklist would be
     annoying.

-Peff