git-jump: pass "merge" arguments to ls-files

We currently throw away any arguments given to "git jump merge". We
should instead pass them along to ls-files, since they're likely to be
pathspecs. This matches the behavior of "git jump diff", etc.

Signed-off-by: Jeff King <peff@peff.net>
---
Just a little wart I noticed while doing a really tricky merge today.

 contrib/git-jump/README   | 3 +++
 contrib/git-jump/git-jump | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

On Tue, Nov 09, 2021 at 11:35:47AM -0500, Jeff King wrote:
> We currently throw away any arguments given to "git jump merge". We
> should instead pass them along to ls-files, since they're likely to be
> pathspecs. This matches the behavior of "git jump diff", etc.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Just a little wart I noticed while doing a really tricky merge today.

This is hilarious to me, because I wrote the exact same patch to skip
some conflicts while resolving what I can only assume is the same merge.

> diff --git a/contrib/git-jump/git-jump b/contrib/git-jump/git-jump
> index 931b0fe3a9..92dbd4cde1 100755
> --- a/contrib/git-jump/git-jump
> +++ b/contrib/git-jump/git-jump
> @@ -39,7 +39,7 @@ mode_diff() {
>  }
>
>  mode_merge() {
> -	git ls-files -u |
> +	git ls-files -u "$@" |

It's kind of unfortunate (maybe not?) that a caller could now run:

    git jump merge --no-unmerged

and get the same results albeit *much* slower. We could limit ourselves
to only accepting pathspecs (by writing `git ls-files -u -- "$@"`), but
that feels overly restrictive. We could also say `"$@" -u`, but that
breaks if the caller writes `--` or `--end-of-options`.

So I think that what you and I both wrote is least bad, but it does make
me cringe a little bit at being able to pass `--no-unmerged` to `git
jump merge`.

Anyway, I know that it's late in the -rc cycle, but I'd be happy to see
something like this get picked up once Junio tags 2.34 and we have
stabilized a little bit.

Thanks,
Taylor

On Tue, Nov 09, 2021 at 11:46:26AM -0500, Taylor Blau wrote:

> On Tue, Nov 09, 2021 at 11:35:47AM -0500, Jeff King wrote:
> > We currently throw away any arguments given to "git jump merge". We
> > should instead pass them along to ls-files, since they're likely to be
> > pathspecs. This matches the behavior of "git jump diff", etc.
> >
> > Signed-off-by: Jeff King <peff@peff.net>
> > ---
> > Just a little wart I noticed while doing a really tricky merge today.
> 
> This is hilarious to me, because I wrote the exact same patch to skip
> some conflicts while resolving what I can only assume is the same merge.

It's possible. :)

> >  mode_merge() {
> > -	git ls-files -u |
> > +	git ls-files -u "$@" |
> 
> It's kind of unfortunate (maybe not?) that a caller could now run:
> 
>     git jump merge --no-unmerged
> 
> and get the same results albeit *much* slower. We could limit ourselves
> to only accepting pathspecs (by writing `git ls-files -u -- "$@"`), but
> that feels overly restrictive. We could also say `"$@" -u`, but that
> breaks if the caller writes `--` or `--end-of-options`.

Yeah. With "git jump diff" and "git jump grep", it's an explicit feature
that we allow extra arguments. That's less likely here, though you could
perhaps do something clever with --recurse-submodules, etc. And while
you could royally screw things up with "--no-unmerged", I think this is
a case of "if it hurts, don't do it".

> Anyway, I know that it's late in the -rc cycle, but I'd be happy to see
> something like this get picked up once Junio tags 2.34 and we have
> stabilized a little bit.

Yeah, obviously no rush at all on this.

-Peff