On 03/27/2014 11:46 PM, Tim Niemueller wrote:
>
> I don't get the idea. What would it do? Currently it pretty much sounds
> like an SSH session to which you login and find all the tools you need
> neatly setup. What am I missing?
It has nothing to do with SSH.
It's an extension for shell application (/usr/bin/sh, like bash, zsh,
dash etc.) which enhances you command line prompt. Data is coming from
plugins. You can configure prompts conditionally, for example you can
have different prompt for different directories.
The most important plugin developed as part of this project is git
plugin. It provides data to display in shell prompt, for example:
- current branch name
- number of dirty files
- merge or rebase status
- number of merge conflicts
- number of commits you are ahead/behind of remote tracking branch
- whether working dir is clean or not
and so on...
There are some possible Fedora-specific extensions too:
- has this package newer commit in Fedora?
- am I owner or comaintainer of this package?
- what is the build status of this package?
Justification
-------------
As a packager who maintains a large number of packages (over 300
currently) I find proper git workflow to be really important to me. And
there are people that own many more Fedora packages than I do.
Moreover, proven packagers often need to commit to git report for
packages they don't own.
Having status line in your shell prompt improves workflow in several
ways, for example:
1. Working with tens or hundreds of git repos requires people to do
stuff in parallel. With git shell prompt you know what's the status of
a git repo immediately after changing directory to a its working dir:
Do I need to fetch from remote? Are there any uncommited changes? Are
there any unpushed commits? etc...
2. If someone pushes to that repo while you are working on it you'll see
it in the status line in real time. Data about commits is coming from
fedmsg. This allows you to rebase your work early. It is important as
commits in Fedora never merge cleanly (unless it's fast-forward) --
there are always merge conflicts in spec changelog and release tag.
3. You know if you have appropriate rights for that repository. Proven
packagers need to take extra steps when commiting to packages they don't
own or comatinatin.
There are other improvements too, it would take me too much time to
describe them all. That's what we have students for :)
Why Fedora?
-----------
You may wonder why this idea has to do with Fedora.
First of all, there are some Fedora-specicic improvements. But that's
not just it.
Fedora heavily relies on git. At the moment of writing this we have
15,071 [1] source packages in rawhide, each of them has its own repo.
Besides that we have repos for deprecated packages, fedorahosted.org and
others. I don't know any other organization which has as many public
git repos as we do. Recent developments (copr, playground repo,
software collections) only complicated the situation or are about to.
Git is a great tool to maintain and rebase patches in Fedora. RPM has
direct support for git (%autosetup macro).
We also often work with upstreams and git is currently the most popular
SCM in free software development.
[1] repoquery -a --qf '%{base_package_name}' | sort -u | wc -l
--
Mikolaj Izdebski
IRC: mizdebsk
>
> Tim
>
> Am 27.03.2014 18:15, schrieb Ratnadeep Debnath:
>> Git shell prompt daemon
>>
>> Status: Proposed
>>
>> Summary of idea: Fedora packaging is heavily dependant on git. Without
>> specialized git tools, maintenance of tens or hundreds of Fedora
>> packages can become tedious.
>>
>> This project is about implementing a deamon which would listen on
>> named pipe to requests from system shell (like bash) and it would
>> respond with command line prompt dependant on context (like status of
>> git repository in given directory) and user configuration.
>>
>> The core of the daemon should not rely on git, but instead be written
>> using plugin framework allowing different plugins to be implemented.
>> Each plugin could provide different information to be displayed in
>> shell prompt.
>>
>> Besides the core, a git plugin should be implemented. This plugin
>> should not call git executable, but instead use a git library (such as
>> libgit2 which has bindings for many languages).
>>
>> Knowledge prerequisite: Git, Linux, any programming language which has
>> bindings for libgit2 [1]
>>
>> Skill level: Medium
>>
>> Contacts: Mikolaj Izdebski [2]
>>
>> Mentor(s): Mikolaj Izdebski [2], Stanislav Ochotnicky [3] (backup)
>>
>> [1]: http://libgit2.github.com/
>> [2]: https://fedoraproject.org/wiki/User:Mizdebsk
>> [3]: https://fedoraproject.org/wiki/User:Sochotni
>>
>> Regards,
>> rtnpro
>>
> _______________________________________________
> summer-coding mailing list
> summer-coding@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/summer-coding
_______________________________________________
summer-coding mailing list
summer-coding@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/summer-coding
