Hi!
On Thu, Apr 22, 2010 at 02:19:02AM +0530, Pavan Kumar Sunkara wrote:
> a) File Structure:
>
> * gitweb.pl -- Main script parsing urls and calling required modules
> * gitweb.css -- The style for the gitweb pages.
> * gitweb.js -- javascript to make gitweb more interactive
> * git-logo.png
> * git-favicon.png
> * Makefile -- Responsible for installing gitweb
> * lib (dir) -- some basic files like config, view and other actions
> * config.pm
> * view.pm
> * default.pm -- this just outputs the list of all projects.
> * {actions}.pm -- One file for every action
(I have reservations to this particular structure and naming, but I
don't think that's crucial for the proposal.)
> The current gitweb makefile makes a gitweb.cgi from the perl script
> and requires a server for it's working. I would like to continue this
> process but the change will be in the gitweb perl script. The new
> script includes config and other basic files, checks the URL, parses
> it, detects the action, uses the output and along with view.pm gives
> out a proper HTML, CSS web page.
Sounds fine in principle.
> The lib directory will also contain
> some basic modules like Gitweb::Repo, Gitweb::Commit which will make
> developing further functionalities easier.
Beware, this might be an awful can of worms. The previous gitweb SoC
project failed to get merged in part due to trying to do something like
this.
I recommend to avoid any large architectural changes and just shuffle
around all the utility routines to lib/Gitweb.pm or so.
> I will be using a static
> file to maintain the list of repositories which is obtained by
> scanning repositories.
Will this be compatible with the current project list file?
> b) Read modules of the client: (most of this need not be written, just
> need to be organised)
>
> 1. See the status of repository [git status]
> 2. Show diff of the current working file compared to HEAD [git diff]
> 3. List all the commits with pagination [git log]
> 4. With every commit we can
> * Visualise trees [git ls-tree]
> * Visualise files and diffs [git show]
> * Visualise annotations [git blame]
> 5. List all branches including remote ones [git branch]
> 6. Search commits, branches, authors etc.. [git grep]
>
> c) Write modules of the client:
>
> 1. Add Existing repositories to the gitweb -- This will list the
> given repo into static list of repos.
> 2. Create new/Clone repositories into a given path [git init | git
> clone] -- This will create new repo and list it
> 3. Add/Remove/Move files [git add | git rm | git mv]
> 4. Stage/Unstage files [git add | git reset]
> 5. Add files to ignore list when u click on 'Ignore' link
> 6. Discard changes to a file in working copy [git reset]
> 7. Commit to the repository with a log message and an optional
> sign-off [git commit]
> 8. Manage branches [git branch]
> 9. A simple branch merging* [git merge]
> 10. Creating tags [git tag]
> 11. Implementing a simple file editor
> 12. Checkout code to a specific commit or branch or tag [git checkout]
> 13. Editing config for remotes [git remote]
> 14. Push to a remote branch [git push]
> 15. Fetch/Pull from a remote branch [git fetch | git pull]
> 16. Garbage collection [git gc | git count-objects | git fsck | git prune]
> 17. Search for a part of code using pickaxe
BTW, I think you could prioritize better, e.g. (5) or (10) is rather
minor thing while (11) or (14),(15) are crucial. But this is not that
important if you are confident you will finish everything listed. ;-)
> * - Merging two branches can be quite complicated. Simple merge
> mentioned above will be just showing you that there are conflicts. But
> you won't be having options to
BTW, I don't think it's really complicated at all in the simple conflict
case - just edit the file and do git add (getting all the file-directory
etc. cases right might be more tedious, but less important).
> d) Usage of the client:
>
> This client can be used in 2 ways.
>
> * Install a local version using instaweb - The gitweb will be only
> accessible by you. You can browse through the git repository using
> read modules and simultaneously work on them using write modules.
> * Install on intranet - A company when installs this gitweb along with
> some other login and account managing scripts will be able to order
> their employees to login and ask them to work on the code with out the
> security risk of providing ssh access to the git repository host. The
> authentication support can be implemented as an optional part of my
> proposal.
> * Install on web - Just like normal gitweb, or enable write modules to
> look like gist.github.com
Note that for the latter two, operation mode without working copy is
essential; I have not seen you address it anywhere.
Good work, I like this better than the first proposal. :-)
--
Petr "Pasky" Baudis
http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates
--
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