Git development
 help / color / mirror / Atom feed
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.

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox