On Sat, 16 May 2009, Timur Tabi wrote: > On Fri, May 15, 2009 at 4:36 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > Gitweb can deal with non-bare repositories. It is only that because > > gitweb is not interested in working area, it shows $GIT_DIR (path to > > repository itself) as name/path to repository. Therefore repo/.git > > for non-bare repositories, because it is repository itself that matters. > > I understand that, but why does gitweb have to punish me because I > give it more than it cares about? Gitweb doesn't punish you for using non-bare repositories. Gitweb is just consistent: all that matters to gitweb is repository itself ($GIT_DIR), therefore it uses 'project/.git' as a project name for non-bare, because this is $GIT_DIR for it. Besides, why do you care that your non-bare repositories have 'project/.git' as their name? As Junio wrote it is a good idea to be able to distinguish between bare and non-bare repositories. Perhaps I should remove description of workaround from the patch... Anyway I'd rather not complicate further 6336 lines long gitweb/gitweb.perl, one of largest scripts in git repository. One would have to add stripping s!/\.git$!! from repository path (project name) on display, and do additional check for $path/.git when checking if what we were given looks like git repository. > > > If you provide access for others, i.e. if those repositories shown in > > gitweb are public repositories, it is much better to use bare > > repositories for that. > > Why? What difference does it make if they clone directly from my > working tree, instead of some shadow repository? Well, best practice is to not change (rewrite) published history. This means that you very strongly shouldn't even use "git commit --amend", neverthemind "git rebase" and reordering patches and squashing bugfixes using "git rebase --interactive" (or other tools like StGit or Guilt) on the branches you meant to share. Because otherwise you would seriously inconvenience developers which base their work your work on shared/published branch. Also you should take into account that if you publish your working, non-bare repositories, all your branches are visible to the world. So unless you tell other developers which branches are meant to share, and which are not, you would have trouble with working on topic branches. And for more complicated features best practices demand that you do them as a series of commits rather than one big complicated patch on feature branch, and it is hard to create a perfect, or just good (so it doesn't look like "A, B, oops fix A, C, oops revert B, oops fix C"), series of commits on first try. And there is also bit of complication for other developers if you, as best practices tell you should, delete no longer used (merged in) short term feature branches; this would require pruning remote-tracking branches by other developers. So unless you work by yourself (and then see git-instaweb), it is really better to have separate public publishing repository, which is bare. -- 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