# [StGit PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' 15 messages from 2007-05-20 to 2007-05-22. Participants: Robin Rosenberg, Yann Dirson, Karl Hasselström, Catalin Marinas. Thread: https://gitlist.dev/t/8253 ## Robin Rosenberg, 2007-05-20 20:03 Subject: [StGit PATCH 0/2] Bash prompt updates Message-ID: <20070520200113.14633.90705.stgit@lathund.dewire.com> URL: https://gitlist.dev/e/20070520200113.14633.90705.stgit%40lathund.dewire.com In-Reply-To: <20070506150852.8985.98091.stgit@yoghurt> ``` Here is a fix to update the bash prompt so it does not use the obsolete current file anymore. Part 2 is my version which uses a different format, mostly because '/' can be part of the branch name. -- robin ``` ## Robin Rosenberg, 2007-05-20 20:04 Subject: [StGit PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: <20070520200403.14633.26644.stgit@lathund.dewire.com> URL: https://gitlist.dev/e/20070520200403.14633.26644.stgit%40lathund.dewire.com In-Reply-To: <20070520200113.14633.90705.stgit@lathund.dewire.com> ``` Signed-off-by: Robin Rosenberg --- contrib/stgbashprompt.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh index 16bb39b..7c5dc76 100755 --- a/contrib/stgbashprompt.sh +++ b/contrib/stgbashprompt.sh @@ -8,8 +8,8 @@ if [ "$PS1" ]; then git_dir=$(git-rev-parse --git-dir 2> /dev/null) || return ref=$(git-symbolic-ref HEAD 2> /dev/null) || return br=${ref#refs/heads/} - top=$(cat $git_dir/patches/$br/current 2>/dev/null) \ - && top="/$top" + top=$(tail -1 $git_dir/patches/$br/applied 2>/dev/null) \ + && top="/$top"; echo "[$br$top]" } PS1='\u@\h:$(__prompt_git)\W\$ ' ``` ## Robin Rosenberg, 2007-05-20 20:04 Subject: [StGit PATCH 2/2] Don't use / as separatar since it is common i branch names Message-ID: <20070520200408.14633.12056.stgit@lathund.dewire.com> URL: https://gitlist.dev/e/20070520200408.14633.12056.stgit%40lathund.dewire.com In-Reply-To: <20070520200113.14633.90705.stgit@lathund.dewire.com> ``` Signed-off-by: Robin Rosenberg --- contrib/stgbashprompt.sh | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh index 7c5dc76..732966a 100755 --- a/contrib/stgbashprompt.sh +++ b/contrib/stgbashprompt.sh @@ -8,9 +8,9 @@ if [ "$PS1" ]; then git_dir=$(git-rev-parse --git-dir 2> /dev/null) || return ref=$(git-symbolic-ref HEAD 2> /dev/null) || return br=${ref#refs/heads/} - top=$(tail -1 $git_dir/patches/$br/applied 2>/dev/null) \ - && top="/$top"; - echo "[$br$top]" + top=$(tail -1 $git_dir/patches/$br/applied 2>/dev/null) + top=${top:-(none)} + echo "[$top@$br]" } PS1='\u@\h:$(__prompt_git)\W\$ ' fi ``` ## Yann Dirson, 2007-05-20 20:46 Subject: Re: [StGit PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: <20070520204627.GR19253@nan92-1-81-57-214-146.fbx.proxad.net> URL: https://gitlist.dev/e/20070520204627.GR19253%40nan92-1-81-57-214-146.fbx.proxad.net In-Reply-To: <20070520200403.14633.26644.stgit@lathund.dewire.com> ``` Note that "tail -1" gives a warning with newer versions, "tail -n 1" should be the proper call. Also I'm not sure it is a good way to look at "applied" file, since Karl IIRC has plans to change this. Better call "stg top" and not touch that again :) On Sun, May 20, 2007 at 10:04:03PM +0200, Robin Rosenberg wrote: > Signed-off-by: Robin Rosenberg > --- > > contrib/stgbashprompt.sh | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh > index 16bb39b..7c5dc76 100755 > --- a/contrib/stgbashprompt.sh > +++ b/contrib/stgbashprompt.sh > @@ -8,8 +8,8 @@ if [ "$PS1" ]; then > git_dir=$(git-rev-parse --git-dir 2> /dev/null) || return > ref=$(git-symbolic-ref HEAD 2> /dev/null) || return > br=${ref#refs/heads/} > - top=$(cat $git_dir/patches/$br/current 2>/dev/null) \ > - && top="/$top" > + top=$(tail -1 $git_dir/patches/$br/applied 2>/dev/null) \ > + && top="/$top"; > echo "[$br$top]" > } > PS1='\u@\h:$(__prompt_git)\W\$ ' > > - > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > !DSPAM:4650aff673931961316905! > ``` ## Robin Rosenberg, 2007-05-20 21:22 Subject: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: <20070520211103.17468.21373.stgit@lathund.dewire.com> URL: https://gitlist.dev/e/20070520211103.17468.21373.stgit%40lathund.dewire.com In-Reply-To: <20070520204627.GR19253@nan92-1-81-57-214-146.fbx.proxad.net> ``` Signed-off-by: Robin Rosenberg s�ndag 20 maj 2007 skrev Yann Dirson: > Note that "tail -1" gives a warning with newer versions, "tail -n 1" > should be the proper call. My man page doesn't mention -N being deprecated, but ok since -n 1 seems to work here too. > Also I'm not sure it is a good way to look at "applied" file, since > Karl IIRC has plans to change this. Better call "stg top" and not > touch that again :) Calling stg is too slow to be be used here. I that command in my first draft for this function and people complained (see the thread named "Bash snippet to show branch and patch in bash prompt"). It takes ~ 0.15s on here which is very noticable, barely below my pain threshold. We'll update the prompt when and if Karl breaks this. It'd probably drain my battery too :/ -- robin contrib/stgbashprompt.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh index 16bb39b..f4817a1 100755 --- a/contrib/stgbashprompt.sh +++ b/contrib/stgbashprompt.sh @@ -8,8 +8,8 @@ if [ "$PS1" ]; then git_dir=$(git-rev-parse --git-dir 2> /dev/null) || return ref=$(git-symbolic-ref HEAD 2> /dev/null) || return br=${ref#refs/heads/} - top=$(cat $git_dir/patches/$br/current 2>/dev/null) \ - && top="/$top" + top=$(tail -n 1 $git_dir/patches/$br/applied 2>/dev/null) \ + && top="/$top"; echo "[$br$top]" } PS1='\u@\h:$(__prompt_git)\W\$ ' ``` ## Robin Rosenberg, 2007-05-20 21:24 Subject: [PATCH 2/2] Don't use / as separatar since it is common i branch names Message-ID: <20070520212205.17468.71900.stgit@lathund.dewire.com> URL: https://gitlist.dev/e/20070520212205.17468.71900.stgit%40lathund.dewire.com In-Reply-To: <20070520204627.GR19253@nan92-1-81-57-214-146.fbx.proxad.net> ``` Don't use / as separatar since it is common i branch names Signed-off-by: Robin Rosenberg diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh index f4817a1..5927e67 100755 --- a/contrib/stgbashprompt.sh +++ b/contrib/stgbashprompt.sh @@ -9,8 +9,8 @@ if [ "$PS1" ]; then ref=$(git-symbolic-ref HEAD 2> /dev/null) || return br=${ref#refs/heads/} top=$(tail -n 1 $git_dir/patches/$br/applied 2>/dev/null) \ - && top="/$top"; - echo "[$br$top]" + top=${top:-(none)} + echo "[$top@$br]" } PS1='\u@\h:$(__prompt_git)\W\$ ' fi ``` ## Karl Hasselström, 2007-05-21 07:48 Subject: Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: <20070521074838.GA32510@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20070521074838.GA32510%40diana.vm.bytemark.co.uk In-Reply-To: <20070520211103.17468.21373.stgit@lathund.dewire.com> ``` On 2007-05-20 23:22:00 +0200, Robin Rosenberg wrote: > söndag 20 maj 2007 skrev Yann Dirson: > > > Also I'm not sure it is a good way to look at "applied" file, > > since Karl IIRC has plans to change this. Better call "stg top" > > and not touch that again :) > > Calling stg is too slow to be be used here. I that command in my > first draft for this function and people complained (see the thread > named "Bash snippet to show branch and patch in bash prompt"). It > takes ~ 0.15s on here which is very noticable, barely below my pain > threshold. > > We'll update the prompt when and if Karl breaks this. Yes, I can confirm that I'm hard at work breaking this. :-) I'm trying out a way to get around the performance bug Catalin found, but I didn't have time to finish it yesterday. If that work is included, you could simply find the top patch by doing git-show-ref and figuring out which patch has the same sha1 as HEAD. But it sucks that stg starts so slowly. It has gotten better, I believe (I think Catalin did some work here?), but 150 ms doesn't really qualify as "instantaneous". -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ``` ## Catalin Marinas, 2007-05-21 09:31 Subject: Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: URL: https://gitlist.dev/e/b0943d9e0705210231j75ef2e57o922f7899f4b5814b%40mail.gmail.com In-Reply-To: <20070521074838.GA32510@diana.vm.bytemark.co.uk> ``` On 21/05/07, Karl Hasselström wrote: > On 2007-05-20 23:22:00 +0200, Robin Rosenberg wrote: > > Calling stg is too slow to be be used here. I that command in my > > first draft for this function and people complained (see the thread > > named "Bash snippet to show branch and patch in bash prompt"). It > > takes ~ 0.15s on here which is very noticable, barely below my pain > > threshold. > > > > We'll update the prompt when and if Karl breaks this. > > Yes, I can confirm that I'm hard at work breaking this. :-) I'm trying > out a way to get around the performance bug Catalin found, but I > didn't have time to finish it yesterday. My plan is to release a 0.13 version pretty soon but without the DAG patches as we might have to test them a bit more. The release after 0.13 I'd like to be a 1.0-rc1 (including the DAG patches) unless we have some other major changes pending. > But it sucks that stg starts so slowly. It has gotten better, I > believe (I think Catalin did some work here?), but 150 ms doesn't > really qualify as "instantaneous". I don't think we can get much slower than this. I modified stg to only load the modules needed for a given command but it still takes around 150ms for a command like 'top'. I don't know any other python tricks to make it start faster. BTW, any of you would like to get added as a member to gna.org/projects/stgit (there are no advantages, only e-mail updates for filed bug reports)? Regards. -- Catalin ``` ## Karl Hasselström, 2007-05-21 10:15 Subject: Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: <20070521101540.GB32510@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20070521101540.GB32510%40diana.vm.bytemark.co.uk In-Reply-To: ``` On 2007-05-21 10:31:09 +0100, Catalin Marinas wrote: > My plan is to release a 0.13 version pretty soon but without the DAG > patches as we might have to test them a bit more. That's reasonable. > The release after 0.13 I'd like to be a 1.0-rc1 (including the DAG > patches) unless we have some other major changes pending. It'd be great to do away with the need to "stg init", but that shouldn't really be a major change (but I haven't started looking at it yet). It would be nice if 1.0 had documentation that didn't have to mention "stg init". > I don't think we can get much slower than this. Oh yes we can ... :-) > I modified stg to only load the modules needed for a given command > but it still takes around 150ms for a command like 'top'. I don't > know any other python tricks to make it start faster. I don't either. We might consider having plumbing written in C or something, and make sure that the plumbing can be called directly if there's need, but it's going to complicate things greatly compared to pure Python. > BTW, any of you would like to get added as a member to > gna.org/projects/stgit (there are no advantages, only e-mail updates > for filed bug reports)? Free bug reports? Sure, I'm in! (I just created a Gna! account: kha) -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ``` ## Karl Hasselström, 2007-05-21 11:39 Subject: Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: <20070521113915.GA3090@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20070521113915.GA3090%40diana.vm.bytemark.co.uk In-Reply-To: <20070521101540.GB32510@diana.vm.bytemark.co.uk> ``` On 2007-05-21 12:15:40 +0200, Karl Hasselström wrote: > We might consider having plumbing written in C or something, and > make sure that the plumbing can be called directly if there's need, > but it's going to complicate things greatly compared to pure Python. What I'm (foggily) envisioning here is to rewrite parts of StGIT (as little as possible) as a C library (libstgit.so?), and call the library both from the Python code, and from a "plumbing" C program (stgit-helper?). We should not try to make the library API stable, just like the current git library. There are two kinds of things we'd want to have in the library: (1) things that are too slow to do in Python, and (2) things that need to be available from stgit-helper in order to avoid Python's startup cost, such as top/applied/unapplied for the bash completion and bash prompt. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ``` ## Catalin Marinas, 2007-05-21 15:17 Subject: Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: URL: https://gitlist.dev/e/b0943d9e0705210817n35e50a6bgb519b693984b3a4b%40mail.gmail.com In-Reply-To: <20070521113915.GA3090@diana.vm.bytemark.co.uk> ``` On 21/05/07, Karl Hasselström wrote: > On 2007-05-21 12:15:40 +0200, Karl Hasselström wrote: > > > We might consider having plumbing written in C or something, and > > make sure that the plumbing can be called directly if there's need, > > but it's going to complicate things greatly compared to pure Python. Yes, it will complicate things. I think StGIT would have progressed at a much slower pace if written in C :-). > What I'm (foggily) envisioning here is to rewrite parts of StGIT (as > little as possible) as a C library (libstgit.so?), and call the > library both from the Python code, and from a "plumbing" C program > (stgit-helper?). We should not try to make the library API stable, > just like the current git library. Apart from the start-up time, I don't see other major slowdowns caused by Python. It would be useful to use a git library directly without invoking external applications (I'm not sure what's the state of a "libgit.a" or what improvement we would get). As for the start-up time, unless you write most of the commands in C, we would still have to load Python modules. If you run stg-prof instead of stg for a simple command like 'top', you can see that the main function takes about 60-70ms, the rest to 150ms reported by the external 'time' is Python start-up and module loading. I had a quick try at using "freeze.py" to generate a binary (well, it includes python bytecodes but it might save time on module look-up) but it got confused by my optimisation to only load module commands based on the stg arguments. Maybe we should try this first. > There are two kinds of things we'd want to have in the library: (1) > things that are too slow to do in Python, and (2) things that need to > be available from stgit-helper in order to avoid Python's startup > cost, such as top/applied/unapplied for the bash completion and bash > prompt. As you probably guessed, I'm not really in favour of re-writing parts of StGIT in C, at least not in the near future, though anyone can fork and re-implement it :-). -- Catalin ``` ## Karl Hasselström, 2007-05-21 15:39 Subject: Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: <20070521153952.GB6474@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20070521153952.GB6474%40diana.vm.bytemark.co.uk In-Reply-To: ``` On 2007-05-21 16:17:22 +0100, Catalin Marinas wrote: > On 21/05/07, Karl Hasselström wrote: > > > On 2007-05-21 12:15:40 +0200, Karl Hasselström wrote: > > > > > We might consider having plumbing written in C or something, and > > > make sure that the plumbing can be called directly if there's > > > need, but it's going to complicate things greatly compared to > > > pure Python. > > Yes, it will complicate things. I think StGIT would have progressed at > a much slower pace if written in C :-). I agree. C is not a good language to write a whole application in. But for the hot spots, C is a reasonable choice. > > What I'm (foggily) envisioning here is to rewrite parts of StGIT > > (as little as possible) as a C library (libstgit.so?), and call > > the library both from the Python code, and from a "plumbing" C > > program (stgit-helper?). We should not try to make the library API > > stable, just like the current git library. > > Apart from the start-up time, I don't see other major slowdowns > caused by Python. I haven't, either. > It would be useful to use a git library directly without invoking > external applications (I'm not sure what's the state of a "libgit.a" > or what improvement we would get). There is no usable git library yet. But once there is, I agree we should use it. > As for the start-up time, unless you write most of the commands in C, > we would still have to load Python modules. If you run stg-prof > instead of stg for a simple command like 'top', you can see that the > main function takes about 60-70ms, the rest to 150ms reported by the > external 'time' is Python start-up and module loading. My suggestion was to have a small stand-alone C program that could do some operations that need to be really fast, such as top/applied/unapplied. It need not have a nice user interface since it's only going to be called by scripts (bash-completion and the like), and it should only handle those operations that _must- avoid the Python startup penalty. And for sanity reasons, it should share code with stgit. > I had a quick try at using "freeze.py" to generate a binary (well, > it includes python bytecodes but it might save time on module > look-up) but it got confused by my optimisation to only load module > commands based on the stg arguments. Maybe we should try this first. I agree that we should try pure-Python optimizations first. > > There are two kinds of things we'd want to have in the library: > > (1) things that are too slow to do in Python, and (2) things that > > need to be available from stgit-helper in order to avoid Python's > > startup cost, such as top/applied/unapplied for the bash > > completion and bash prompt. > > As you probably guessed, I'm not really in favour of re-writing > parts of StGIT in C, at least not in the near future, though anyone > can fork and re-implement it :-). I wouldn't do it just for fun, either. But if it's a prerequisite to get good enough performance for something we really want, and all else has failed, I'd be willing to argue for the introduction of a C library and helper application. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ``` ## Yann Dirson, 2007-05-21 18:57 Subject: Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: <20070521185731.GS19253@nan92-1-81-57-214-146.fbx.proxad.net> URL: https://gitlist.dev/e/20070521185731.GS19253%40nan92-1-81-57-214-146.fbx.proxad.net In-Reply-To: ``` On Mon, May 21, 2007 at 10:31:09AM +0100, Catalin Marinas wrote: > BTW, any of you would like to get added as a member to > gna.org/projects/stgit (there are no advantages, only e-mail updates > for filed bug reports)? You should not disregard the added bonus of being able to be assigned some of the bugs and tasks reported there :) Best regards, -- Yann. ``` ## Catalin Marinas, 2007-05-22 12:11 Subject: Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: URL: https://gitlist.dev/e/b0943d9e0705220511u2b3ed46fg220af2cce26fef96%40mail.gmail.com In-Reply-To: <20070521153952.GB6474@diana.vm.bytemark.co.uk> ``` On 21/05/07, Karl Hasselström wrote: > My suggestion was to have a small stand-alone C program that could do > some operations that need to be really fast, such as > top/applied/unapplied. It need not have a nice user interface since > it's only going to be called by scripts (bash-completion and the > like), and it should only handle those operations that _must- avoid > the Python startup penalty. And for sanity reasons, it should share > code with stgit. There is one more case to consider - people using NFS-mounted directories. The applied/unapplied commands would be even slower and the language overhead be negligible. Another workaround would be to always generate the applied/unapplied files when the stack structure changes. -- Catalin ``` ## Karl Hasselström, 2007-05-22 13:29 Subject: Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current' Message-ID: <20070522132927.GA12626@diana.vm.bytemark.co.uk> URL: https://gitlist.dev/e/20070522132927.GA12626%40diana.vm.bytemark.co.uk In-Reply-To: ``` On 2007-05-22 13:11:13 +0100, Catalin Marinas wrote: > On 21/05/07, Karl Hasselström wrote: > > > My suggestion was to have a small stand-alone C program that could > > do some operations that need to be really fast, such as > > top/applied/unapplied. It need not have a nice user interface > > since it's only going to be called by scripts (bash-completion and > > the like), and it should only handle those operations that _must- > > avoid the Python startup penalty. And for sanity reasons, it > > should share code with stgit. > > There is one more case to consider - people using NFS-mounted > directories. The applied/unapplied commands would be even slower and > the language overhead be negligible. > > Another workaround would be to always generate the applied/unapplied > files when the stack structure changes. Yes, we could do that. These files would only be accurate when the stack was last modified with StGIT and not plain git, but that might be acceptable. Hmm. Since the only way plain git modifies the stack is by changing HEAD (we assume the user doesn't manually mess with the patch refs), we might also write down the value of HEAD for which the applied/unapplied files are valid, so that the caller could call "stg applied" if the applied file was out of date. But that's quite a hassle to have to reimplement every time. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ```