Re: [PATCH] gitweb: Document that gitweb deals with bare repositories

[Jakub Narebski <jnareb@gmail.com>]

On Sat, 16 May 2009, Timur Tabi wrote:
> On Fri, May 15, 2009 at 4:36 PM, Jakub Narebski <jnareb@gmail.com> 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