Re: [RFC] xl command for visualizing recent history

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 4, 2020, 20:30 UTC
Message-ID: <nycvar.QRO.7.76.6.2001042115550.46@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqk168cjn0.fsf@gitster-ct.c.googlers.com>

Hi,

On Fri, 3 Jan 2020, Junio C Hamano wrote:

Show 10 quoted lines

> Matthew DeVore <matvore@comcast.net> writes:
>
> > On Thu, Oct 31, 2019 at 09:26:48AM +0100, Johannes Schindelin wrote:
> >>
> >> am stands for "apply mbox", and I think that the only reason it is not
> >> called `git apply-mbox` is that the Linux maintainer uses it a lot and
> >> wanted to save on keystrokes.
>
> No need to give an incorrect speculation if you do not know the
> history in this discussion.

Oh, but where would be the fun in _not_ speculating???

:-)

> Back then, the command to apply mbox contents existed and was called
> "git applymbox".  "am" was invented as a better replacement with more
> rational behaviour and set of command line arguments.

Now that you mention it, I vaguely remember reading about it. But even back then, I was not so much enthused with the idea of exporting Git history into emails and then turning those emails back into Git history (now with "New And Improved!" commit names), so I did actually not pay much attention.

As you might recall, I was also a fervent opponent of `git rebase` (which I think was based on `git am` from the get-go), claiming that history should not be rewritten. Well, what did I know. I went on to write `git-edit-patch-series.sh` which you accepted into Git as `git rebase --interactive`, so there.

Show 11 quoted lines

> >> Having said that, I do agree that `xl` is not a good name for this.
> >> It is neither intuitive, nor is it particularly easy to type (on a
> >> US-English keyboard, the `x` and the `l` key are far apart), and to
> >> add
> >
> > There is a subjective element to this, but I would consider it easy to
> > type since it is using two different hands....
>
> Give descriptive name to the command, define an alias of your choice and
> use it privately.  Nobody would be able to guess what "git xl" or "git
> extra-long" command would do ;-)

I thought I made the point already that such short names are prone to be already used by users' aliases, and that shorter command names are very likely to break someone's setup.

While I do not have any `xl` alias defined, I have 20 custom two-letter aliases, and I would be utterly surprised if there were less than a thousand Git users who defined `xl` to mean something already (by now, there are _a lot_ of Git users out there, and it would be foolish to assume that less than even the tiny fraction of a percent that translates into a thousand users didn't use this alias). While one might say that forcing a thousand users to adjust is not a big deal, I would counter that we should not, unless really necessary.

And in this case, I deem it totally not necessary at all.

But again, I was wrong before (see e.g. the `git rebase` comment above), so what do I know.

In any case, as stated before, I would like to see this feature be implemented as a `git log` (or even `git rev-list`) option before implementing a dedicated command.

In other words, this new feature should be treated as a _mode_ rather than a new command. The command can come later, just like `git whatchanged` is essentially a special-case version of `git log`.

Ciao, Dscho