From: Phillip Wood <phillip.wood123@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Emily Shaffer <emilyshaffer@google.com>
Cc: Matthew DeVore <matvore@google.com>,
git@vger.kernel.org, Matthew DeVore <matvore@gmail.com>,
matvore@comcast.net, jonathantanmy@google.com,
jrnieder@gmail.com, steadmon@google.com
Subject: Re: [RFC] xl command for visualizing recent history
Date: Thu, 31 Oct 2019 20:04:00 +0000 [thread overview]
Message-ID: <b0169b2b-0d8a-ee27-d0f4-6c7a6df55b5d@gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1910310851300.46@tvgsbejvaqbjf.bet>
Hi
On 31/10/2019 08:26, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 30 Oct 2019, Emily Shaffer wrote:
>
>> On Mon, Oct 28, 2019 at 05:30:23PM -0700, Matthew DeVore wrote:
>>> From: Matthew DeVore <matvore@gmail.com>
>>> [...]
>
> In addition, I would think that the introduction of ephemeral refs
> should deserve its own patch. Such ephemeral refs might come in handy
> for more things than just `xl` (or whatever better name we find).
>
> The design of such ephemeral refs is thoroughly interesting, too.
I agree the ephemeral refs are interesting and could be really useful
> One very obvious question is whether you want these refs to be
> worktree-specific or not. I would tend to answer "yes" to that question.
If we go for a per-terminal namespace as you suggest below I'm not sure
if we want/need them to be per worktree as well. I don't have a clear
idea how I'd want to use ephemeral refs if I changed worktree but kept
working in the same terminal.
> Further, another obvious question is what to do with those refs after a
> while. They are _clearly_ intended to be ephemeral, i.e. they should
> just vanish after a reasonably short time. Which raises the question:
> what is "reasonably short" in this context? We would probably want to
> come up with a good default and then offer a config setting to change
> it.
Maybe keep them around for a couple of days? Even that might be longer
than we need.
> Another important aspect is the naming. The naming schema you chose
> (`h/<counter>`) is short-and-sweet, and might very well be in use
> already, for totally different purposes. It would be a really good idea
> to open that schema to allow for avoiding clashes with already-existing
> refs.
>
> A better alternative might be to choose a naming schema that cannot
> clash with existing refs because it would not make for valid ref names.
> I had a look at the ref name validation, and `^<counter>` might be a
> better naming schema to begin with: `^1` is not a valid ref name, for
> example.
That's an interesting idea, it's short and wont tread on anyone's toes.
> Side note: why `h/`? I really tried to think about possible motivations
> and came up empty.
>
> Another aspect that I think should be considered: why limit these
> ephemeral refs to `git xl`? I cannot count how often I look through
> some `git log <complicated-options> -- <sophisticated-magic-refspecs>`
> to find a certain commit and then need to reference it. I usually move
> my hand to move the mouse pointer and double click, then Shift-Insert
> (which is awkward on this here keyboard because Insert is Fn+Delete, so
> I cannot do that with one hand), and I usually wish for some better way.
>
> A better way might be to introduce an option for generating and
> displaying such ephemeral refs, in my case it would be good to have a
> config setting to do that automatically for every `git log` call that
> uses the pager, i.e. is interactive.
Having them as a feature of the rev listing machinery rather than
specific to a particular command sounds like a good way to go.
> Finally, I could imagine that in this context, we would love to have
> refs that are purely intended for interactive use, and therefore it
> would make sense to try to bind them to the process ID of the process
> calling `git`, i.e. the interactive shell. That way, when I have two
> terminal windows, they would "own" their separate ephemeral refs.
I like that idea, though I think it should probably be based around
getsid() rather than getppid() (I'm not sure how that translates to windows)
Best Wishes
Phillip
>>> The test cases show non-trivial output which can be used to get an idea
>>> for what the command is good for, though it doesn't capture the
>>> coloring.
>>>
>>> The primary goals of this command are:
>>>
>>> a) deduce what the user wants to see based on what they haven't pushed
>>> upstream yet
>>> b) show the active branches spatially rather than as a linear list (as
>>> in "git branch")
>>> c) allow the user to easily refer to commits that appeared in the
>>> output
>>>
>>> I considered making the h/# tags stable across invocations such that a
>>> particular hash will only be tagged with a different number if ~100
>>> other hashes are tagged since the hash was last tagged. I didn't
>>> actually implement it this way, instead opting for always re-numbering
>>> the hashes on each invocation. This means the hash number is
>>> predictable based on the position the hash appears in the output, which
>>> is probably better that encouraging users to memorize hash numbers (or
>>> use them in scripts!).
>>
>> If you're worried about folks using something like this in a script (and
>> I would be, given that it's dynamically assigning nicknames to hashes)
>> then you probably ought to mark it as a porcelain command in
>> command-list.txt.
>
> I would like to caution against targeting scripts with this. It is too
> easy for two concurrently running scripts to stumble over each other.
>
> Scripts should use safer methods that already exist, like grabbing the
> hash while looking for a specific pattern (`sed`'s hold space comes to
> mind).
>
> Ciao,
> Dscho
>
next prev parent reply other threads:[~2019-10-31 20:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-29 0:30 [RFC] xl command for visualizing recent history Matthew DeVore
2019-10-31 0:39 ` Emily Shaffer
2019-10-31 8:26 ` Johannes Schindelin
2019-10-31 20:04 ` Phillip Wood [this message]
2019-11-01 18:58 ` Johannes Schindelin
2020-01-03 20:14 ` Matthew DeVore
2020-01-03 21:30 ` Junio C Hamano
2020-01-04 20:30 ` Johannes Schindelin
2020-01-04 22:56 ` Junio C Hamano
2020-01-04 21:21 ` Johannes Schindelin
2020-02-07 1:39 ` Matthew DeVore
2020-01-03 2:51 ` Matthew DeVore
2019-10-31 10:16 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b0169b2b-0d8a-ee27-d0f4-6c7a6df55b5d@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=jonathantanmy@google.com \
--cc=jrnieder@gmail.com \
--cc=matvore@comcast.net \
--cc=matvore@gmail.com \
--cc=matvore@google.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=steadmon@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).