git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: GSoC 2010: "Integrated Web Client for git" proposal

From
Petr Baudis <pasky@suse.cz>
Date
Apr 22, 2010, 20:25 UTC
Message-ID
<20100422202501.GJ10939@machine.or.cz>
In-Reply-To
<k2le72faaa81004211349o1628ed42s4fa0aa412006128@mail.gmail.com>
  Hi!
On Thu, Apr 22, 2010 at 02:19:02AM +0530, Pavan Kumar Sunkara wrote:
Show 13 quoted lines
> 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.)
Show 6 quoted lines
> 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?
Show 35 quoted lines
> 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).

Show 15 quoted lines
> 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
Previous: Pavan Kumar SunkaraNext: Junio C Hamano
Message 28 of 39 in “GSoC 2010: "Integrated Web Client for git" proposal”
  1. Christian CouderApr 15, 2010
  2. Jakub NarebskiApr 18, 2010
  3. Petr BaudisApr 18, 2010
  4. Jakub NarebskiApr 18, 2010
  5. Petr BaudisApr 18, 2010
  6. Pavan Kumar SunkaraApr 18, 2010
  7. Jakub NarebskiApr 18, 2010
  8. Petr BaudisApr 18, 2010
  9. Pavan Kumar SunkaraApr 19, 2010
  10. Matthieu MoyApr 19, 2010
  11. Junio C HamanoApr 19, 2010
  12. Pavan Kumar SunkaraApr 19, 2010
  13. Petr BaudisApr 19, 2010
  14. Matthieu MoyApr 19, 2010
  15. Pavan Kumar SunkaraApr 19, 2010
  16. Matthieu MoyApr 19, 2010
  17. Petr BaudisApr 19, 2010
  18. Pavan Kumar SunkaraApr 19, 2010
  19. Petr BaudisApr 20, 2010
  20. Jakub NarebskiApr 18, 2010
  21. Petr BaudisApr 18, 2010
  22. Jakub NarebskiApr 19, 2010
  23. Petr BaudisApr 19, 2010
  24. Pavan Kumar SunkaraApr 19, 2010
  25. Petr BaudisApr 20, 2010
  26. Jakub NarebskiApr 20, 2010
  27. Pavan Kumar SunkaraApr 21, 2010
  28. Petr BaudisApr 22, 2010
  29. Junio C HamanoApr 22, 2010
  30. Petr BaudisApr 23, 2010
  31. Junio C HamanoApr 23, 2010
  32. Pavan Kumar SunkaraApr 22, 2010
  33. Christian CouderApr 23, 2010
  34. Pavan Kumar SunkaraApr 23, 2010
  35. Pavan Kumar SunkaraApr 19, 2010
  36. Jakub NarebskiApr 19, 2010
  37. Pavan Kumar SunkaraApr 19, 2010
  38. Jakub NarebskiApr 19, 2010
  39. Pavan Kumar SunkaraApr 20, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.