Re: Small repository problems

[Dustin J. Mitchell]

On Wed, Jul 22, 2009 at 11:42 AM, Peter Simons<address@hidden> wrote:
> If ac_prog_xsltproc.m4 were to be renamed to m4/ac_prog_xsltproc.m4,
> then Gitweb would treat it like a new file; the history page wouldn't
> show the earlier commits anymore.

Arguably, this is a bug in gitweb, although I think it makes sense not
to do copy/move detection in a web interface.

> Anyway, I don't feel strongly about this subject; it is true that the
> submodule causes the entire workflow to be a little awkward. Does anyone
> have an alternative suggestion how to organize the repository? What do
> you think we should do?

Options I can think of:

 1. merge 'maint' and 'master' together, just leaving everything at
the top level

 2. damn the historical torpedoes and 'git mv *.m4 m4'

 3. use 'git filter-branch' to build a new branch with the macros
under m4/, but with the same history.  This, of course, requires
everyone to rebase onto a completely new history, but that's a
one-time pain.

I prefer option 3: I think most folks who would have to rebase are
either on this list, or are folks who have a git checkout of the
repository in which they 'git pull' and then copy whatever macros they
want into their project.  The former can use some creative 'git rebase
--onto' to fix their branches.  The latter can be assisted with a
warning on the aa webpage giving the proper git recipe to get the
newest macros checked out.

This is balancing developer pain against user-visible history, so I
think that if the pain of rebasing is too high, we should go with
option 2.

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com