Re: [PATCH] git-jump: pick a mode automatically when invoked without arguments
- From
Greg Hurrell <greg@hurrell.net>
- Date
- May 19, 2026, 09:03 UTC
- Message-ID
- <8f4b75d8-f875-434a-8fc5-06a708cbc53f@app.fastmail.com>
- In-Reply-To
- <agXb1SXKnA69L9ak@mbp>
On Thu, May 14, 2026, at 5:40 PM, Erik Cervin Edin wrote:
Show 31 quoted lines
> On 26/05/08 09:07AM, Greg Hurrell via GitGitGadget wrote:
> > -usage: git jump [--stdout] <mode> [<args>]
> > +usage: git jump [--stdout] [<mode>] [<args>]
>
> The usage message makes <mode> optional but doesn't explain what
> happens when you omit it. Seems worth documenting the auto-detect behavior
> there too.
>
> 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?
>
> Also, if this is going to grow into a proper auto-detect heuristic, it
> might be cleaner as a first-class mode rather than logic spliced into the
> argument parser. Something like:
>
> mode_auto() {
> if test -n "$(git ls-files -u)"; then
> mode_merge "$@"
> elif ! git diff --quiet; then
> mode_diff "$@"
> elif ! git diff --cached --check >/dev/null 2>&1; then
> mode_ws --cached "$@"
> else
> return 0
> fi
> }
>
> That way `git jump auto` works explicitly, bare `git jump` defaults
> to it (just `set -- auto` when $# -lt 1), and the usage text can
> document the heuristic. It also keeps the detection and dispatch in
> one place in case someone wants to tweak the priority later.All of those suggestions sound reasonable to me. Jeff, do you agree? If so, I can update the patch.
Best wishes, Greg