Junio C Hamano <gitster@xxxxxxxxx> writes:
> Because this is a new feature, instead of breaking existing users
> and forcing them to do something different they did not have to
> (namely, set and export the GIT_JUMP_IGNORE_STDOUT_CHECK environment
> variable), we should instead make this a non-default behaviour and
> those who want it should explicitly opt-in to trigger it, perhaps
> like:
>
> open_editor() {
> if ! test -t 1 && test -n "$GIT_JUMP_AUTO_CAT"
> then
> cat "$1"
> else
> editor=`git var GIT_EDITOR`
> eval "$editor -q \$1"
> fi
> }
>
> so that existing users won't get affected by this change at all,
> while allowing you and other vim users to set and export the
> environment variable just once.
>
> Unilaterally breaking, and ignoring when you are told you are
> breaking, possible existing users, without giving them any escape
> hatch, is simply irresponsible, and not something done in this
> project. But I am sensing that you are not listening to and
> thinking about what you hear before you respond, so I will stop
> spending time on this topic for now, and wait until others chime in.
Well, I lied ;-)
I somehow doubt that users of vim types "!git jump diff" (or
whichever submode they want) from within vim's command prompt;
wouldn't they typically wrap the invocation in a vim macro?
If my suspicion is correct, with an opt-in feature like the above
(which is designed not to hurt existing users), the vim users can
change their macro definition to not just invoke "git jump
<whatever>", but invoke "GIT_JUMP_AUTO_CAT=yes git jump <whatever>",
i.e. tell "git jump" that you are opting into the "cat the file,
instead of launching GIT_EDITOR". So with just a one-time setting,
vim (and other similar editor) users would benefit without hurting
others.
For that matter, instead of introducing GIT_JUMP_AUTO_CAT, the same
mechanism can be used to run "GIT_EDITOR=cat git jump <whatever>",
i.e. tell "git jump" that it is expected to run "cat" as its
editor, from such a vim macro ;-)
