Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'
- From
Karl Hasselström <kha@treskal.com>
- Date
- May 22, 2007, 13:29 UTC
- Message-ID
- <20070522132927.GA12626@diana.vm.bytemark.co.uk>
- In-Reply-To
- <b0943d9e0705220511u2b3ed46fg220af2cce26fef96@mail.gmail.com>
On 2007-05-22 13:11:13 +0100, Catalin Marinas wrote:
Show 16 quoted lines
> On 21/05/07, Karl Hasselström <kha@treskal.com> 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