Re: why does git set X in LESS env var?

[Christoph Anton Mitterer <calestyo@scientia.org>]

On Fri, 2023-10-13 at 06:43 +0200, Dragan Simic wrote:
> > *If* some changes were made to how git handles this, it might
> > perhaps
> > be worth to consider not to touch LESS at all, but only add the
> > required settings via command line arguments (i.e. -F -R ...).
> 
> Actually, that would be wrong.  If someone sets $LESS or $PAGER (or 
> $GIT_PAGER, more specifically), it's up to the utility that invokes
> the 
> pager internally not to override the user preferences configured
> through 
> these environment variables.  That's how everyone can customize the 
> pager behavior.

Well, but if its clear that the output would otherwise be garbage (e.g.
because -R is missing).

In any case right now we have the situation that a user cannot just
easily set LESS in his environment, with a minimum set of options, and
git's use of less will continue flawlessly out of the box, as the -R
would be missing.


> > Or perhaps only remove options from it, if they're known to break
> > the
> > behaviour with git (like -+R might).
> 
> Again, not the way the whole thing with pagination works.  If someone
> sets their environment variables wrong, it's simply the way they want
> it, and it isn't anyone else's business to attempt fixing it 
> automatically.

Well, I wouldn't agree with that.
LESS foremost a env var to configure less (surprise ^^).

If git (or anyone else) uses less internally, e.g. because they don't
want to implement their own pager, fine... but then they cannot just
blindly assume that LESS is set only for git's (or any other tool's
needs).

So I'd say the proper way is rather that any such tool makes sure, that
any options strictly required as set no matter what. Just as e.g. delta
does.


> Well, fragile or not, that's the way it works.  It has its downsides
> for 
> sure, but it's all about having each utility handle the environment 
> carefully and document it in its man page(s), so the users can also 
> carefully craft the values of their customized environment variables.

Sure, but from a user's view, the use of less (or anything else) within
git is conceptually completely opaque.

In less' manpage LESS isn't documented as "oh and you must make sure -R
is included or otherwise git will break"...



> $LESS can be seen as a global set of the common options for less(1), 

o.O ... but, as I've described, one cannot really use it as that:

If I globally set e.g. LESS="F" because my desire is to make less
always exit as soon as the file fits on a screen, which I think is a
reasonable thing to do, git would no longer add "R" and output would
break.


> You don't have to define an alias, there's $GIT_PAGER for that
> purpose, 
> as I already explained above.

Well, yes... and as I've said before, one could also solve it via
git_config... but the problem stays the same... as soon as someone
wants to use LESS as global less options just as you described it
yourself, git will no longer worker properly because of the missing -R.

And actually if one would use GIT_PAGER one would again defeat the
purpose of a allegedly global options LESS, because unless one does
something like GIT_PAGER="${LESS}R" it wouldn't see any changes made to
LESS.


> Moreover, the whole idea of the various utilities touching the $LESS 
> variable internally is to provide sane defaults to the users that
> don't 
> configure $LESS, $PAGER, etc. on their own.

Then I don't see what the big problem would be to just do it via a
command argument - if someone really has ever some reasons to remove --
RAW‐CONTROL‐CHARS from the command options when less is invoked via git
... then he could still go into git_config and set that manually.

But it would seem to me that the overall handling would be much more
what one expects, than when doing the same via LESS.



> I don't know what delta is and how it actually paginates its outputs,
> but it should follow the rules of the environment-based pager 
> configuration that I described in detail above.

Well, AFAIU, it doesn't and for good reasons :-)


Anyway... I think all necessary things have been said and this thread
has grown far to large with only semi-related stuff... so thanks for
all the replies why git uses "-X".


Cheers,
Chris.