On 2007-05-22 13:11:13 +0100, Catalin Marinas wrote:
> On 21/05/07, Karl Hasselström <kha@xxxxxxxxxxx> 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@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
