patch, 2 partsUpdate the bash prompt from 'applied' instead of the obsolete 'current'

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

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---

 contrib/stgbashprompt.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

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 <robin.rosenberg@dewire.com>

s�ndag 20 maj 2007 skrev Yann Dirson:

My man page doesn't mention -N being deprecated, but ok since -n 1 seems
to work here too.
 

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(-)

On 2007-05-20 23:22:00 +0200, Robin Rosenberg wrote:

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".

On 21/05/07, Karl Hasselström <kha@treskal.com> 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. 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.

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.

On 2007-05-21 10:31:09 +0100, Catalin Marinas wrote:

That's reasonable.

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".

Oh yes we can ... :-)

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.

Free bug reports? Sure, I'm in! (I just created a Gna! account: kha)

On 2007-05-21 12:15:40 +0200, Karl Hasselström wrote:

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.

On 21/05/07, Karl Hasselström <kha@treskal.com> wrote:

Yes, it will complicate things. I think StGIT would have progressed at a much slower pace if written in C :-).

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.

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 :-).

On 2007-05-21 16:17:22 +0100, Catalin Marinas wrote:

I agree. C is not a good language to write a whole application in. But for the hot spots, C is a reasonable choice.

I haven't, either.

There is no usable git library yet. But once there is, I agree we should use it.

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 agree that we should try pure-Python optimizations first.

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.

On 21/05/07, Karl Hasselström <kha@treskal.com> wrote:

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.

On 2007-05-22 13:11:13 +0100, Catalin Marinas wrote:

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.

On Mon, May 21, 2007 at 10:31:09AM +0100, Catalin Marinas wrote:

You should not disregard the added bonus of being able to be assigned some of the bugs and tasks reported there :)

Best regards,

    Don't use / as separatar since it is common i branch names
    
    Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---

 contrib/stgbashprompt.sh |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)