[Open discussion on idea] Git shell prompt daemon

[Lukky513]

Hi, I'm Łukasz Raszka - also applying for the very same project. I wanted
to address some of the concerns.

> Out of curiosity, why is repo tool by Google not suited here?
IMHO because of plugins. The idea is not only about making a git tool, but
something extensible and more useful - for example making a plugin doing
"du -sh" in the background, or maybe viewing quota when you want to tidy up
your home directory (as stupid as it sounds). This gives many possibilities
- more or less sensible. Some easily done in your .bashrc, but not
necessarily.

> Here your libgit solution could help, but how
> would this scale to more plugins without a large performance penalty?
Plugins shouldn't work all at the same time, unless there's a specific
need. After all, how much useful information can you put into the prompt?
Daemon should run idle until some kind of virtual environment (kind of like
virtualenv which most of you probably know) script is run, forcing it to
load eg. the git plugin. Maybe you could load another plugin and
concatenate the results, but I suppose not more than 2-3 of them.
Performance wouldn't be an issue considering the architecture - maybe
rather the nature of plugins - some being heavier, like git or that svn
beast could become, while other, like forementioned quota viewer being much
lighter.

> And ahead of time: sounds like
> it could become a second tracker/beagle desaster caching tons of unused
> data being one more nuisance...
That's entirely possible. But on the other hand, you might need to enter
the commands like 'git log' to achieve the same result, wasting your and
CPUs' time, and plugins might be smart enough to watch directory tree for
changes, so that they wouldn't do unnecessary grinding. Hard to foresee.

> The preferred way for me is "something from bashrc/etc."
> However, I don't know how to change prompt dynamically when user
> doesn't run any commands/press keys.
IIRC, zsh has some facilities allowing it to be done; I don't think it'd be
a good idea, though. Personally, I just like the reactive prompt better
than proactive one - it's not that good to stop in the middle of typing
because something changed - especially in case such as this, when daemon
actions ought to be passive in their nature (providing status information
rather than actually doing anything). And there's always the line feed if
someone wants updated info.

Thanks to Mikołaj and Alexander for explaining the idea!

Regards,
Łukasz

2014-03-30 10:41 GMT+02:00 Alexander Mezin <mezin.alexander at gmail.com>:

> 2014-03-28 23:24 GMT+07:00 Tim Niemueller <tim at niemueller.de>:
> > In general, do you intend to extend the bash, or have something started
> > with the bashrc/profile/your-shell-file-here?
> The preferred way for me is "something from bashrc/etc."
> However, I don't know how to change prompt dynamically when user
> doesn't run any commands/press keys.
>
> Maybe both ways could be implemented: patch/extension for shell, and
> something that generates PS1 every time as fallback.
> Though I don't think bash devs will be happy to accept such patch.
>
> Mikolaj, what do you think about it?
>
> > One typical complaint
> > about stuff executed each time to form the prompt is that it can slow
> > things down considerably. Here your libgit solution could help, but how
> > would this scale to more plugins without a large performance penalty?
> > Maybe some info about the architecture this would use could help here.
> Actually, performance problems is what I personally want to solve in
> this project.
> Daemon loads only once, so loading a lot of plugins shouldn't be a problem.
>
> I didn't try to think about architecture yet. Designing good
> architecture is a part of the project, and I will start working on it
> only after I will have everything working for git.
> However, I don't think there will be something complex.
>
> > The daemon idea shounds sensible, talking via dbus?
> D-bus isn't neccessary here. Socket should be sufficient.
>
> > Still, how would this be integrated with the command line.
> Actually, answer to this question is at beginning of the message.
>
> > And ahead of time: sounds like
> > it could become a second tracker/beagle desaster caching tons of unused
> > data being one more nuisance...
> As I noted in my proposal, the only way I see here is trial-and-error.
> But I am sure something will work.
>
> > I do think this is useful, there are just so many questions and details
> > unclear currently.
> It's boring when everything is clear from the beginning, isn't it?
> _______________________________________________
> summer-coding mailing list
> summer-coding at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/summer-coding
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/summer-coding/attachments/20140330/0e526245/attachment.html>