Re: Moving to git

[Thomas Schwinge]

Hello!

On Tue, Apr 28, 2009 at 12:39:48AM +0200, I wrote:
> A bit of a status update.

... and again -- perhaps that last one?

> The CVS to Git conversion is mostly finished.
> 
> There are still some quirks with converting the
> gnumach-1-branch-Xen-branch, but I'm working on resolving these with the
> help of the conversion program's author, Simon 'corecode' Schubert, whose
> fromcvs / rcsparse combo I finally ended up using, by the way.

In case that someone is interested -- what was wrong with the previous
import: the method fromcvs uses to decide where in the timeline to put
commits that have been aggregated from more than one CVS files' revisions
is to put them in the place where the aggregate's part with the earliest
timestamp would have been put -- thus pre-dating all parts of the
aggregate that would originally appear later.  (That was the short
version.)  This is for one an aesthetic issue, and for another changing
this algorithm to putting commits at the position of the latest timestamp
made this mysterious gnumach-1-branch-Xen-branch conversion problem go
away!

So, with this fromcvs change, I re-converted the repositories -- only
hurd and gnumach were actually affected by this issue.

Olaf asked whether we could fix the author and committer information for
the changesets.  This can't be done reliably in an automated way and
surely no one wants to inspect 10,000+ changesets manually.  As I
consider a correct-believed but nevertheless incorrect automatic
conversion worse than the current one where you exactly know that the
information is not accurate, I decided to leave this alone as is.

Also, there was the idea of aggregating all the individual one-file,
[...], then ChangeLog commits into aggregates, but this also can't be
done reliably in an automated fashion without a lot of manual corrections
(as could be seen in the glibc CVS to Git conversion), so I also left
that alone.

But what I did, for extra kicks, is that I rebuilt (or: reconnected) the
history of various GNU Mach branches: HEAD, oskit-branch,
gnumach-1-branch, gnumach-1-branch-Xen-branch -- including the merging
between them.  Looks nice with gitk!

Fetch the whole shebang from <http://git.savannah.gnu.org/cgit/hurd/>.
Give it a try.  Unless someone finds any issues that really need to be
corrected, these trees shall be the new basis for our collaboration!

Later, I'll push a few branches containing Hurd patches applied (libpager
/ ext2fs extensions, TLS support, ...), so that these can be easily
merged into your local working branches.  Also, I'll add branches for the
former GSoC projects -- are there any former GSoC people (CCed) who
already have done their work somewhere else than in our CVS repository,
or should I take the history contained in the CVS repository?


> Here is one additional topic I want to confirm with you all before
> committing it: the duplication of ChangeLog snippets and commit log
> messages is a pain.  However, it is not mandatory to maintain ChangeLog
> files in the VCS sources -- it's fine with the GNU Coding Standards to
> only create ChangeLog files for distribution tarballs (where one doesn't
> have access to the VCS logs anymore).  GNU Coreutils is already using
> this scheme, and I got it confirmed on the GNU-internal maintainers'
> mailing list that this is indeed fine.  When needed, the ChangeLog files
> would be created automatically from the VCS commit messages.  (We can
> steal all the mechanisms from GNU Coreutils.)
> 
> Commit messages would then have this mandatory format: [...]
> 
> Any objections?

There was a bit of support, and no objections, so that is it; see section
``Commit messages'' on
<http://www.gnu.org/software/hurd/rules/source_repositories.html>.


Regards,
 Thomas

signature.asc
Description: Digital signature