From: Phillip Wood Date: Thu, 31 Oct 2019 20:04:00 GMT Subject: Re: [RFC] xl command for visualizing recent history Message-ID: In-Reply-To: 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 >>> [...] > > 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/`) 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 `^` 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 -- ` > 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 >