Re: Small repository problems

[Francesco Salvestrini]

Hi Peter,

On Saturday 25 July 2009, Peter Simons wrote:
> 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. :-)

You're welcome ;-)

>  > 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?

I't my fault, I've been unclear. It was the (somewhat unrelated) explanation 
of my usual setup for other projects, nothing more. I use submodules, more or 
less, as git-submodule documentation says:

"... They are not to be confused with remotes, which are meant mainly for 
branches of the same project; submodules are meant for different projects you 
would like to make part of your source tree, while the history of the two 
projects still stays completely independent and you cannot modify the 
contents of the submodule from within the main project. ..."

>  > [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.

Yes, all changeset-like SCMs suffer that drawback ... but it is not so 
important compared to the benefits.

> 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.

I agree.

> This would ensure that Gitweb finds the complete file history for m4/foo.m4.

Here came my points againts bounding too much to gitweb, for macro history 
tracking:

>  > What about a macro rename that could happen ?

[SNIP]

>  > And a macro removal due to obsolescence ?

[SNIP]

I was pointing to the gitweb limitations, seen from the user looking for a 
macro history on gitweb. By sticking to gitweb, we now have the following 
situation:

* We cannot move macros freely without harming gitweb history (thus my first 
point)

* Gitweb could not show to the user a removed macro nor shows a moved macro 
(thus the second point)

With the current assumptions we are in the same situation when someone would 
like to rename a macro later its introduction into the archive (e.g: macro 
names refactory in order to be AX_<macro-name>/ax_<file-name> compliant).

Hence I think that gitweb is not the macro history tracking tool we should 
bound to.

Thus came my proposal:

>  > 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.

By not being bounded to gitweb for macro-history tracking ... we could be free 
to handle the repository as we like, without constraints.

We have two targets IMHO:

* maintainers: those who use 'git log --follow' rather than looking into a 
webapp

* users: those who could find more detailed/specific information into a 
prebuilt set of pages than harvesting into gitweb pages

At the end of the day: I'll give a helping hand on that issue ASAP.

Have a good day,
Francesco

-- 
        A man was reading The Canterbury Tales one Saturday morning, when his
wife asked "What have you got there?"  Replied he, "Just my cup and Chaucer."