zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Peter Grayson <pete@jpgrayson.net>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH] Remove StGit patch detection from vcs_info
Date: Sun, 13 Nov 2022 04:30:40 +0000	[thread overview]
Message-ID: <20221113043040.GG27622@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <603fd1b9-1b11-4729-99cb-19e1c4ef8b37@app.fastmail.com>

Peter Grayson wrote on Sat, Nov 12, 2022 at 09:46:02 -0500:
> On Fri, Nov 11, 2022, at 6:49 AM, Daniel Shahaf wrote:
> > [re #2]: It sounds like StGit 2.x support can be implemented at the cost
> > of one fork(2) for those who don't use StGit and under a microsecond for
> > those who do.  That doesn't sound like a deal breaker at all.
> 
> Running `stg series` with StGit 2.0 takes about 12ms in my environment.
> StGit 1.5 it is about 32ms. Not a microsecond, but perhaps acceptable
> nonetheless.
> 

To be clear, are these figures the duration of the «stg series
--noprefix --applied» invocation?

What's the impact on people who don't have stg(1) installed, or who have
stg(1) installed but are currently in a worktree that doesn't use StGit?
I.e., are those figures immediately after `git init`, or in a worktree
that has a StGit patch stack, or?

In general, 32ms for everyone might be too much (what if another
third-party tool wanted to do its own elif branch that also spent 32ms
for everyone?  That'd be 64ms in total and counting…).  However, if the
32ms would only be seen by users of an EOL'd stg(1), we can relax the
threshold a bit.  On the other hand, if it's 32ms just in cases where
stg(1) is used… well, there doesn't seem to be much we /can/ do there.
Perhaps hide some or all of the work behind an opt-in switch.  (For
instance, the default settings show only the topmost applied patch, so
if it's possible to tell stg(1) not to emit any other patches, that
might help the code finish more quickly.)

From the "Is your computer plugged in?" department: Is that 32ms figure
on hot disk cache with .pyc files already having been generated?

Cheers,

Daniel

> 
> > Cheers,
> >
> > Daniel
> >
> >> Signed-off-by: Peter Grayson <pete@jpgrayson.net>
> >> ---
> >>  Functions/VCS_Info/Backends/VCS_INFO_get_data_git | 11 ++---------
> >>  1 file changed, 2 insertions(+), 9 deletions(-)
> >> 
> >> diff --git a/Functions/VCS_Info/Backends/VCS_INFO_get_data_git b/Functions/VCS_Info/Backends/VCS_INFO_get_data_git
> >> index e45eebc8e..a3f4dbdf0 100644
> >> --- a/Functions/VCS_Info/Backends/VCS_INFO_get_data_git
> >> +++ b/Functions/VCS_Info/Backends/VCS_INFO_get_data_git
> >> @@ -184,15 +184,8 @@ fi
> >>  VCS_INFO_adjust
> >>  VCS_INFO_git_getaction ${gitdir}
> >>  
> >> -local patchdir=${gitdir}/patches/${gitbranch}
> >> -if [[ -d $patchdir ]] && [[ -f $patchdir/applied ]] \
> >> -   && [[ -f $patchdir/unapplied ]]
> >> -then
> >> -    # stgit
> >> -    git_patches_applied=(${(f)"$(< "${patchdir}/applied")"})
> >> -    git_patches_unapplied=(${(f)"$(< "${patchdir}/unapplied")"})
> >> -    VCS_INFO_git_handle_patches
> >> -elif [[ -d "${gitdir}/rebase-merge" ]]; then
> >> +local patchdir
> >> +if [[ -d "${gitdir}/rebase-merge" ]]; then
> >>      # 'git rebase -i'
> >>      patchdir="${gitdir}/rebase-merge"
> >>      local p
> >> -- 
> >> 2.38.1
> >> 
> >>
> 


  parent reply	other threads:[~2022-11-13  4:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25 20:43 [PATCH] Remove _stgit completion script Peter Grayson
2022-10-31  9:19 ` Daniel Shahaf
2022-10-31 10:13   ` StGit 2.0 and vcs_info (was: Re: [PATCH] Remove _stgit completion script) Daniel Shahaf
2022-11-01  3:00   ` [PATCH] Remove _stgit completion script Peter Grayson
2022-11-01  3:04     ` [PATCH] Remove StGit patch detection from vcs_info Peter Grayson
2022-11-11 11:49       ` Daniel Shahaf
2022-11-12 14:46         ` Peter Grayson
2022-11-12 15:42           ` [PATCH] Updated StGit patch detection in vcs_info Peter Grayson
2022-11-13  4:58             ` Daniel Shahaf
2022-11-16 20:45             ` [PATCH v2] " Peter Grayson
2022-12-08 14:52               ` [PATCH v3] " Peter Grayson
2022-12-08 22:06                 ` Daniel Shahaf
2022-12-08 22:08                   ` [PATCH] vcs_info git: Check the get-unapplied style as documented (was: [PATCH v3] Updated StGit patch detection in vcs_info) Daniel Shahaf
2022-12-09  0:59                   ` [PATCH v3] Updated StGit patch detection in vcs_info Peter Grayson
2022-12-09  1:37                     ` Daniel Shahaf
2022-12-10 12:55                       ` Peter Grayson
2022-12-10 13:31                         ` Daniel Shahaf
2022-11-13  4:30           ` Daniel Shahaf [this message]
2022-11-14  3:38             ` [PATCH] Remove StGit patch detection from vcs_info Peter Grayson
2022-11-14  5:17               ` Mikael Magnusson
2022-11-14 13:21                 ` Daniel Shahaf
2022-11-14 13:15               ` Daniel Shahaf
2022-11-16 19:38                 ` Peter Grayson

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221113043040.GG27622@tarpaulin.shahaf.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=pete@jpgrayson.net \
    --cc=zsh-workers@zsh.org \
    /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://git.vuxu.org/mirror/zsh/

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 NNTP newsgroup(s).