Re: Small repository problems

[Peter Simons]

Hi Francesco,

 > Since I had multiple copies of gnulib for mine and others projects I changed
 > that approach slightly, using different ways (depending on the project):
 >
 > A) Use a GNULIB environment variable which points to the same gnulib clone
 >
 > B) Use a makefile 'update' target which downloads the required
 > scripts/text-files only (from gnulib: git-version-gen, gitlog-to-changelog,
 > announce-gen, INSTALL, COPYINGv2). Something like autoconf and automake do

You are right. I removed the gnulib submodule. The boostrap.sh script now
assumes that gnulib-tool is in $PATH. That is good enough for all practical
purposes; we really don't need to track gnulib's HEAD, which is what a
submodule would do. Thanks. :-)


 > I use submodules plainly: they are part of my source trees and I cannot or
 > I'm not willing to modify them from the submodule thus the ssh url in m4
 > directory required the explanation that came with your mail.

I am uncertain whether I understand your workflow. Personally, I want both
'maint' and 'master' checked out via SSH, because I want to commit into both
branches, and I want to do so without having to switch branches every time. The
maint branch needs a checked-out copy of master anyway. Why don't you want to
commit into it?


 > [The current structure] bases itself upon the gitweb infrastructure (or
 > cgit, or whatever savannah-hackers will choose to use in the future).

At the root of the problems appears to be git, because it represents a "rename"
by deleting one file and adding another. It is possible to recognize from the
changeset that a renaming took place, but this is a fairly expensive operation,
so most web front-ends to git don't offer it.

What we could do is to create a re-based version of master, say 'm4', in which
all macros have been moved into an m4/ directory. Then we move all macros in
master into an m4/ directory (so that it's identical with m4), and then merge
both maint and m4 into master. The result would be a perfectly valid master
branch (no savannah hacker intervention required) in which the same set of
files would have the exact same history in two different locations. This would
ensure that Gitweb finds the complete file history for m4/foo.m4.


 > What about a macro rename that could happen ?

When a macro was renamed in the past, I usually added a note to the old version
that marked it as obsolete (and referred to the new macro), but I left the file
in place for about 6 months. Then I deleted it.


 > And a macro removal due to obsolescence ?

I did the same thing: I marked the macro as obsolete, left it in place for
about half a year, and then I deleted the file.


 > Since the site is built automatically ... what about building that
 > per-macro-history (including obsolescence, removal and so on) automatically?

I would like that very much. The generated output would probably a lot nicer
for the users than having to navigate Gitweb.

Take care,
Peter