On Wed, 19 May 2010, Pavan Kumar Sunkara wrote: > On Wed, 19 May 2010 01:05:57 +0200, Jakub Narebski wrote: > > Well, I can understand that. > > > > There are two options how to resolve this issue without adding yet > > another script (although on the other hand git-web-gui / git-client > > could share code with git-instaweb just like git-difftool and > > git-mergetool do). > > > > First is to leave git-instaweb similar to how it is now, with pid file, > > server config file, gitweb config file, etc. in $GIT_DIR/gitweb, but > > if it is invoked outside any git repository, start it in "repository > > administration" mode, i.e. on the page that allows one to create new > > repository or clone repository. > > But this solution requires starting of many apache servers on many > ports which is quite complicated and even messier. I agree with that. I guess that git-instaweb was created mainly for the situation where you work in single repository, and does not support well situation where you move from repository to repository, and run git-instaweb in different repositories. As I wrote earlier: Now, current git-instaweb behavior has its quirks, but having git-instaweb show _current_ repository is a very important feature, and I'd rather we didn't lose it in transition. > > The alternate solution would be to follow the idea implemented in this > > patch, namely per-user pid file, gitweb config file, server config file > > etc. and the *list of projects* file in $HOME/.gitweb (or whenever > > XDG / FHS / LSB says it should be named), _but_ add an easy way to add > > a new project (a new repositoey) to list. > > The feature *Adding repository to client* in my project proposal will > take care of this. That's good, but... > > Perhaps even make > > 'git instaweb', when run from inside git repository, add automatically > > current repository to list (unless it is present there already), and > > perhaps open 'summary' page for said repository. > > Yeah, we can do that but I think I will do it in another commit. ...this is really needed, in my opinion. I agree that it should be in separate commit. -- Jakub Narebski Poland -- 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