Re: Moving to git

[olafBuddenhagen]

Hi,

On Sun, Jan 04, 2009 at 12:05:07AM +0100, Thomas Schwinge wrote:

> Only convert GNU Mach's gnumach-1-branch, GNU MIG's HEAD, GNU Hurd's
> HEAD.
> 
>     With the exception of the GNU Mach Xen branch and the Hurd GSoC
>     branches, these are the only branches that see active development.

So? No need to drop dead branches -- they can still be interesting for
reference.

It's not like dropping them helps with anything...

>     For the GNU Mach Xen branch, I'd like Samuel to tell when that one
>     is ready for being merged into the main GNU Mach 1 branch and then
>     I intend to do that merge as one big aggregated ``blob'' (i.e.,
>     without preserving the individual development, testing, debugging,
>     etc. commits.  The same holds for the GSoC branches.

Don't do that. The whole point of a revision control system is to
preserve history... A "blob" commit is unmanageable.

If you think the history of the branch(es) is too messy, you can of
course start a new branch, say xen-cleanup. This new branch should still
contain a series of individual changes though, even if they don't
reflect actual development history.

(The latter is the standard practice in Linux development, BTW.)

> Exclude all automatically regeneratable and Debian package maintenance
> files from the conversion.
> 
>     These files are no longer present in current checkouts (general
>     change of policy), but they do occupy a non-insignificant amount
>     of space in revision history, and are not interesting with respect
>     to preserving their history.  (They might be interesting if
>     someone indeed wants to build an old version, but this is a
>     corner-case that can be worked around easily.)
> 
>     The files will simply be excluded from the conversion.  ChangeLog
>     entries referncing them will not be changed in flight (too
>     time-consuming for no net benefit).  Instead a follow-up clean-up
>     patch will weed out all ChangeLog entries referencing them.

Sounds like a lot of additional work and potential confusion, for very
little benefit...

> Split Hurd modules into separate repositories.

I stand by what I said on this topic before: *If* we decide to make such
a change, it should be done independently of the Git migration.

It would hold up the migration; it would mix a purely technial action
with fundamental decisions.

>     Rationale: split as far as it's still making sense.  There is no
>     reason to have an interger hashing library, a pthread
>     implementation, an ext2 file system interpreter, libc amendments,
>     Hurd interfaces definition files, a library for providing an
>     uniform interface to Mach ports, etc. in the same repository.

Is there a reason to keep them seperate?...

>     libihash and libpthread are shared between Hurd and Viengoos.

I agree that these should be split out, but probably also not during the
git migration...

>     Checking the state after having done a whole-repository conversion
>     yields several change sets that span files in more than one of the
>     new modules.

Indeed, it's not possible to properly disentangle the modules
retrospectively. So we *have* to keep the original history, even if we
really want the split to happen ultimately.

This is also a reason why the split should happen only after the git
conversion.

>       * A few others are for interface changes and follow-up
>       adjustment in the interface-using modules (libihash rewrite, for
>       example). (Likewise for build system enhancements or changes, as
>       adding uselocale for libthreads, or adding libncursesw for
>       utils/console-ncurses.c, for example.)  Or adding a driver for
>       streamio devices and adding a stanza for these in the MAKEDEV
>       script at the same time.  Also, there are a few (notable!)
>       interface changes, where the aggregated documentation in `doc/'
>       has been updated together with committing the interface change.
>       Likewise for changes where the top-level TODO or tasks file has
>       been updated together with committing a change.  All these
>       changes will be broken up.  Future interface changes will be
>       done using some sort of versioning.

This is the main reason why I'm not convinced the split is a good idea
at all. We would need to start some proper versioning, which is quite a
pain. And what would the benefit be? It's not like we ever release these
modules seperately... (At least not in the forseeable future.)

-antrik-